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.