[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <09CD8E2A-6438-48AC-9D60-F661471EE00F@shiz.me>
Date: Mon, 1 Jun 2015 17:39:46 +0200
From: Shiz <hi@...z.me>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 2/2] build: overhaul wrapper script system for multiple wrapper support
> On 01 Jun 2015, at 16:47, Rich Felker <dalias@...c.org> wrote:
>
> There are two reasons I prefer the approach I described:
>
> 1. It's better not to auto-enable wrappers unless we're pretty
> confident they work. The wrappers are not magically universal; they're
> a way to use musl with a preexisting non-musl-targeted toolchain that
> meets a fairly large set of internal assumptions, and they won't
> necessarily work with arbitrary toolchains. In particular I'm pretty
> sure musl-gcc does not work with Rob's toolchains from Aboriginal
> Linux that are using their own wrapper (named gcc) around an internal
> gcc elsewhere, and presumably (being uclibc based) these would even be
> detected as "ok for wrapper”.
I’d like to note that a __GLIBC__ check would not help here either
presumably, as uclibc defines __GLIBC__ as well. :)
> 2, A false positive for enabling the wrapper (installing it on a
> musl-native system) is worse than a false-negative (omitting it) since
> native systems/cross-compilers are intended as the first-class usage
> case and wrappers are more of a demo/minor usage case. I can't safe
> for sure, but I suspect there might be minor breakage (versus a
> full-featured native toolchain) in using the wrappers on top of an
> already-native toolchain, and I don't want to ྀmislead users to do this
> by installing a script that looks like it's meant to be used.
>
> I don't believe the dumpmachine approach is at all robust for gcc
> versions less than gcc 6 where musl support is upstream, and it's
> worse than the current dynamic linker check. There are no musl-cross
> patches at all for gcc versions prior to 4.0.3, whereas gcc3 works
> well and some dists (e.g. Sabotage) are even using it to bootstrap.
Understood, I wasn’t aware of this. On Gentoo’s musl profile, the gcc
CHOST is reconfigured to $arch-gentoo-linux-musl, so -dumpmachine works
as expected on every gcc it builds:
# gcc -dumpmachine
x86_64-gentoo-linux-musl
I assumed other musl distros would do something similar.
So I see your use case for testing in C code itself as opposed to testing
compiler features. That being said, I’m still not at all a fan of __GLIBC__,
for reasons mentioned in the previous post. While a false-positive is worse
than a false-negative, I feel just solely testing for this provides a large
opportunity for false-negatives, and even some false positives as you yourself
mentioned in point one.
It’s a tough thing to check thoroughly and accurately, but I do not think
checking __GLIBC__ is at all the solution either.
-S
Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
