|
Message-ID: <20150629173035.GS1173@brightrain.aerifal.cx> Date: Mon, 29 Jun 2015 13:30:35 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: [PATCH v3 2/3] build: fix musl-targeting toolchain test On Mon, Jun 29, 2015 at 07:35:21AM -0700, Isaac Dunham wrote: > On Sun, Jun 28, 2015 at 11:08:20PM +0200, Shiz wrote: > > the old test was broken in that it would never fail on a toolchains built > > without dynamic linking support, leading to the wrapper script possibly being > > installed on compilers that do not support it. in addition, the new test is > > portable across compilers: the old test only worked on GCC. > > > > the new test works by testing whether the toolchain libc defines __GLIBC__: > > most non-musl Linux libc's do define this for compatibility even when they > > are not glibc, so this is a safe bet to check for musl. in addition, the > > compiler runtime would need to have a somewhat glibc-compatible ABI in the > > first place, so any non-glibc compatible libc's compiler runtime might not > > work. it is safer to disable these cases by default and have the user enable > > the wrappers manually there using --enable-wrapper if they certain it works. > > A long while back, someone reported successfully using a FreeBSD gcc > to build musl, then using that + musl-gcc to build programs that > worked using the Linux emulation layer on FreeBSD. > They submitted a patch with a BSD makefile at that point. This is probably a sufficiently unusual setup to warrant manually enabling the wrapper. I suspect additional work is needed to get the linker to output the right OS type in the ELF header. Unless a FreeBSD GCC toolchain wrapped by musl-gcc can automatically generate working binaries with no further modification or options, I don't think it's appropriate to auto-enable the wrapper there. Rich
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.