From koorogi at koorogi.info Sun Jan 5 08:22:27 2014 From: koorogi at koorogi.info (Bobby Bingham) Date: Sun, 5 Jan 2014 02:22:27 -0600 Subject: [Aboriginal] Build error when system has a cross compiler already Message-ID: <20140105082227.GA1957@duality.lan> I'm running into a build error with aboriginal that seems to be related to the fact that I already have an SH4 cross-compiler toolchain installed on my system. First, the error itself. When aboriginal tries to compile the kernel: sh4-ld: unrecognized option '--build-id' Digging around in the kernel makefiles a bit, it looks like it does try checking if the linker supports the --build-id flag. Looks like the check amounts roughly to: build/simple-cross-compiler-sh4/bin/sh4-gcc -Wl,--build-id -nostdlib -x c /dev/null -o /tmp/foo Which on my system produces this output: /usr/libexec/gcc/sh-superh-linux/ld: warning: cannot find entry symbol _start; defaulting to 00000000004000d8 Note the path to ld -- the sh4-gcc built by aboriginal is apparently running the SH4 linker I have installed on my system, which is from binutils 2.24, which supports the --build-id option. That explains why the kernel thinks the linker supports it. But then the kernel build actually uses the sh4-ld built by aboriginal to link, and this is from an older version of binutils and doesn't support --build-id. Indeed, uninstalling the SH4 toolchain on my system fixes the aboriginal build. I don't have the first clue how gcc decides what linker to run, but I'm hoping someone here has some insight how to fix this, short of uninstalling my toolchain. Thanks. -- Bobby Bingham -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From rob at landley.net Sun Jan 5 16:54:00 2014 From: rob at landley.net (Rob Landley) Date: Sun, 05 Jan 2014 10:54:00 -0600 Subject: [Aboriginal] Build error when system has a cross compiler already In-Reply-To: <20140105082227.GA1957@duality.lan> References: <20140105082227.GA1957@duality.lan> Message-ID: <52C98E28.1040404@landley.net> On 01/05/14 02:22, Bobby Bingham wrote: > I'm running into a build error with aboriginal that seems to be related > to the fact that I already have an SH4 cross-compiler toolchain > installed on my system. After host-tools.sh runs, none of the host binaries should be in the $PATH except 7 cherry picked native compiler binaries (which are symlinked from the new $PATH). In addition, I wrap my compiler with a binary that parses the command line and rewrites it to start with --nostdinc --nostdlib and then manually adds back each build component explicitly on the command line so gcc doesn't do ANY SEARCH, because it's really bad at it. It also adds the correct ld and cc1 and all that as the first entry in the $PATH. But of course having that be the first entry in the $PATH doesn't mean that gcc won't randomly flail around and find unrelated crap, why would I think that? (At one point, I tried patching gcc to remove the layers of bad path logic they'd accumulated over time. When my patch passed 10,000 lines of code removed, I gave up and did the wrapper.) > First, the error itself. When aboriginal tries to compile the kernel: > sh4-ld: unrecognized option '--build-id' > > Digging around in the kernel makefiles a bit, it looks like it does try > checking if the linker supports the --build-id flag. Looks like the > check amounts roughly to: > build/simple-cross-compiler-sh4/bin/sh4-gcc -Wl,--build-id -nostdlib -x c /dev/null -o /tmp/foo > > Which on my system produces this output: > /usr/libexec/gcc/sh-superh-linux/ld: warning: cannot find entry symbol _start; defaulting to 00000000004000d8 > > Note the path to ld -- the sh4-gcc built by aboriginal is apparently > running the SH4 linker I have installed on my system, which is from > binutils 2.24, which supports the --build-id option. That explains why > the kernel thinks the linker supports it. And it found a binary that's not in the $PATH at runtime. How? It's not in the $PATH when simple-cross-compiler.sh runs, is it? Because host-tools.sh ran already and populated build/host and the next script's include.sh should see that and trim the $PATH to point _just_ to that... Right, obviously I'm not currenty reproducing this here. Where did you get this toolchain? I have no idea how to reproduce it? My first wild guess at fixing it would be the attached file. Put it in "sources/patches" and see if that fixes it? But... how would it find it there either? (How does gcc know this binary exists in the first place?) All I know about that patch it didn't _break_ anything obvious in my build... Another potential fix would be to tell it to make the second stage cross compiler, which it does with the original $PATH removed. But again, if I don't understand what's going wrong, I have no idea if that fixes it... > But then the kernel build > actually uses the sh4-ld built by aboriginal to link, and this is from > an older version of binutils and doesn't support --build-id. > > Indeed, uninstalling the SH4 toolchain on my system fixes the aboriginal > build. I don't have the first clue how gcc decides what linker to run, > but I'm hoping someone here has some insight how to fix this, short of > uninstalling my toolchain. My ccwrap binary rewrites the kernel command line to start with --nostdinc --nostdlib and then manually tells it where all the headers and libraries live for what the rest of the command line is doing. (Because otherwise I couldn't _stop_ it from looking in crazy places.) So a _third_ approach I could try is making ccwrap plug this leak. Except if it's a hardwired absolute path it's looking at (which is what that DEFAULT_CRAP did, I grepped for instances of "ld" and that looked most dubious), even the wrapper couldn't stop it short of ptracing the child process and vetoing the syscall (not going there). Please try the patch, and if that doesn't fix it I'm going to need more information. (Preferably a way to reproduce it here.) Thanks, Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc-core-stopdefaults.patch Type: text/x-patch Size: 888 bytes Desc: not available URL: From koorogi at koorogi.info Sun Jan 5 21:34:46 2014 From: koorogi at koorogi.info (Bobby Bingham) Date: Sun, 5 Jan 2014 15:34:46 -0600 Subject: [Aboriginal] Build error when system has a cross compiler already In-Reply-To: <52C98E28.1040404@landley.net> References: <20140105082227.GA1957@duality.lan> <52C98E28.1040404@landley.net> Message-ID: <20140105213446.GA25364@duality.lan> I know my mail was short on information. I'm starting from a position of knowing gcc does all sorts of crazy things you've had to work around, but not knowing what these things are or where to look for them. You've given me a couple places to start looking, so without further ado ... On Sun, Jan 05, 2014 at 10:54:00AM -0600, Rob Landley wrote: > [...] > > First, the error itself. When aboriginal tries to compile the kernel: > > sh4-ld: unrecognized option '--build-id' > > > > Digging around in the kernel makefiles a bit, it looks like it does try > > checking if the linker supports the --build-id flag. Looks like the > > check amounts roughly to: > > build/simple-cross-compiler-sh4/bin/sh4-gcc -Wl,--build-id -nostdlib -x c /dev/null -o /tmp/foo > > > > Which on my system produces this output: > > /usr/libexec/gcc/sh-superh-linux/ld: warning: cannot find entry symbol _start; defaulting to 00000000004000d8 > > > > Note the path to ld -- the sh4-gcc built by aboriginal is apparently > > running the SH4 linker I have installed on my system, which is from > > binutils 2.24, which supports the --build-id option. That explains why > > the kernel thinks the linker supports it. > > And it found a binary that's not in the $PATH at runtime. How? It's not > in the $PATH when simple-cross-compiler.sh runs, is it? Because > host-tools.sh ran already and populated build/host and the next script's > include.sh should see that and trim the $PATH to point _just_ to that... The $PATH during simple-cross-compiler.sh does not containing any system directories. It's got, in order: build/simple-cross-compiler-sh4/bin build/host build/host/fallback-1 build/host/fallback-2 > > Right, obviously I'm not currenty reproducing this here. Where did you > get this toolchain? I have no idea how to reproduce it?' I built this toolchain locally using Gentoo's crossdev tool. I can put together tarballs and upload them somewhere, but I think there's still more investigation I can do myself before it comes to that. > > My first wild guess at fixing it would be the attached file. Put it in > "sources/patches" and see if that fixes it? But... how would it find it > there either? (How does gcc know this binary exists in the first place?) > All I know about that patch it didn't _break_ anything obvious in my > build... The patch doesn't help. > > Another potential fix would be to tell it to make the second stage cross > compiler, which it does with the original $PATH removed. But again, if I > don't understand what's going wrong, I have no idea if that fixes it... I don't think this will help. See below, but it looks like it's trying a whole bunch of directories that have nothing to do with the $PATH. > [...] > So a _third_ approach I could try is making ccwrap plug this leak. > Except if it's a hardwired absolute path it's looking at (which is what > that DEFAULT_CRAP did, I grepped for instances of "ld" and that looked > most dubious), even the wrapper couldn't stop it short of ptracing the > child process and vetoing the syscall (not going there). I've started stracing gcc, and it looks like it is searching a hardcoded list of paths, even with your patch. I've attached the relevant looking excerpt from the strace output. It shows gcc searching a number of paths for collect2, which is apparently then responsible for invoking the real linker [1]. The first several directories searched for collect2 are under the aboriginal build directory, then it switches to looking under /usr/libexec and /usr/lib, and then it switches back to more directories under the aboriginal build directory and evantually finds the correct collect2. The system collect2 that I have is under /usr/libexec/gcc/sh-superh-linux/4.8.2, which the aboriginal gcc doesn't find because of the different gcc version. But when collect2 runs, it _does_ find the system ld, because that's part of binutils and not stored in a directory specific to the gcc version. Now, I still have to see if I can figure out where this fixed set of directories is coming from ... [1]: http://gcc.gnu.org/onlinedocs/gccint/Collect2.html -- Bobby Bingham -------------- next part -------------- stat("/home/koorogi/projects/aboriginal/build/simple-cross-compiler-sh4/sh-superh-linux/bin/../libexec/gcc/sh-superh-linux/4.2.1/collect2", 0x7fff4ca3fce0) = -1 ENOENT (No such file or directory) stat("/home/koorogi/projects/aboriginal/build/simple-cross-compiler-sh4/sh-superh-linux/bin/../libexec/gcc/collect2", 0x7fff4ca3fce0) = -1 ENOENT (No such file or directory) stat("/home/koorogi/projects/aboriginal/build/simple-cross-compiler-sh4/libexec/gcc/sh-superh-linux/4.2.1/collect2", 0x7fff4ca3fce0) = -1 ENOENT (No such file or directory) stat("/home/koorogi/projects/aboriginal/build/simple-cross-compiler-sh4/libexec/gcc/sh-superh-linux/4.2.1/collect2", 0x7fff4ca3fce0) = -1 ENOENT (No such file or directory) stat("/home/koorogi/projects/aboriginal/build/simple-cross-compiler-sh4/libexec/gcc/sh-superh-linux/collect2", 0x7fff4ca3fce0) = -1 ENOENT (No such file or directory) stat("/home/koorogi/projects/aboriginal/build/simple-cross-compiler-sh4/lib/gcc/sh-superh-linux/4.2.1/collect2", 0x7fff4ca3fce0) = -1 ENOENT (No such file or directory) stat("/home/koorogi/projects/aboriginal/build/simple-cross-compiler-sh4/lib/gcc/sh-superh-linux/collect2", 0x7fff4ca3fce0) = -1 ENOENT (No such file or directory) stat("/usr/libexec/gcc/sh-superh-linux/4.2.1/collect2", 0x7fff4ca3fce0) = -1 ENOENT (No such file or directory) stat("/usr/libexec/gcc/sh-superh-linux/collect2", 0x7fff4ca3fce0) = -1 ENOENT (No such file or directory) stat("/usr/lib/gcc/sh-superh-linux/4.2.1/collect2", 0x7fff4ca3fce0) = -1 ENOENT (No such file or directory) stat("/usr/lib/gcc/sh-superh-linux/collect2", 0x7fff4ca3fce0) = -1 ENOENT (No such file or directory) stat("/home/koorogi/projects/aboriginal/build/simple-cross-compiler-sh4/sh-superh-linux/bin/../lib/gcc/sh-superh-linux/4.2.1/../../../../sh-superh-linux/bin/sh-superh-linux/4.2.1/collect2", 0x7fff4ca3fce0) = -1 ENOENT (No such file or directory) stat("/home/koorogi/projects/aboriginal/build/simple-cross-compiler-sh4/sh-superh-linux/bin/../lib/gcc/sh-superh-linux/4.2.1/../../../../sh-superh-linux/bin/collect2", 0x7fff4ca3fce0) = -1 ENOENT (No such file or directory) stat("/home/koorogi/projects/aboriginal/build/simple-cross-compiler-sh4/lib/../sh-superh-linux/bin/sh-superh-linux/4.2.1/collect2", 0x7fff4ca3fce0) = -1 ENOENT (No such file or directory) stat("/home/koorogi/projects/aboriginal/build/simple-cross-compiler-sh4/lib/../sh-superh-linux/bin/collect2", {st_mode=S_IFREG|0755, st_size=1428755, ...}) = 0 access("/home/koorogi/projects/aboriginal/build/simple-cross-compiler-sh4/lib/../sh-superh-linux/bin/collect2", X_OK) = 0 vfork(Process 27720 attached [pid 27720] execve("/home/koorogi/projects/aboriginal/build/simple-cross-compiler-sh4/lib/../sh-superh-linux/bin/collect2", ["/home/koorogi/projects/aborigina"..., "--eh-frame-hdr", "-m", "shlelf_linux", "-dynamic-linker", "/lib/ld-linux.so.2", "-o", "/tmp/foo", "-L/home/koorogi/projects/aborigi"..., "-L/home/koorogi/projects/aborigi"..., "-L/home/koorogi/projects/aborigi"..., "--dynamic-linker", "/lib/ld-uClibc.so.0", "-rpath-link", "/home/koorogi/projects/aborigina"..., "--build-id", ...], [/* 73 vars */] [pid 27717] <... vfork resumed> ) = 27720 [pid 27717] wait4(27720, [pid 27720] <... execve resumed> ) = 0 [pid 27720] uname({sys="Linux", node="duality", ...}) = 0 [pid 27720] brk(0) = 0x1b3e000 [pid 27720] brk(0x1b3f1c0) = 0x1b3f1c0 [pid 27720] arch_prctl(ARCH_SET_FS, 0x1b3e880) = 0 [pid 27720] brk(0x1b601c0) = 0x1b601c0 [pid 27720] brk(0x1b61000) = 0x1b61000 [pid 27720] rt_sigaction(SIGCHLD, {SIG_DFL, [CHLD], SA_RESTORER|SA_RESTART, 0x413790}, {SIG_DFL, [], 0}, 8) = 0 [pid 27720] rt_sigaction(SIGQUIT, {SIG_IGN, [QUIT], SA_RESTORER|SA_RESTART, 0x413790}, {SIG_DFL, [], 0}, 8) = 0 [pid 27720] rt_sigaction(SIGQUIT, {0x402990, [QUIT], SA_RESTORER|SA_RESTART, 0x413790}, {SIG_IGN, [QUIT], SA_RESTORER|SA_RESTART, 0x413790}, 8) = 0 [pid 27720] rt_sigaction(SIGINT, {SIG_IGN, [INT], SA_RESTORER|SA_RESTART, 0x413790}, {SIG_DFL, [], 0}, 8) = 0 [pid 27720] rt_sigaction(SIGINT, {0x402990, [INT], SA_RESTORER|SA_RESTART, 0x413790}, {SIG_IGN, [INT], SA_RESTORER|SA_RESTART, 0x413790}, 8) = 0 [pid 27720] rt_sigaction(SIGALRM, {SIG_IGN, [ALRM], SA_RESTORER|SA_RESTART, 0x413790}, {SIG_DFL, [], 0}, 8) = 0 [pid 27720] rt_sigaction(SIGALRM, {0x402990, [ALRM], SA_RESTORER|SA_RESTART, 0x413790}, {SIG_IGN, [ALRM], SA_RESTORER|SA_RESTART, 0x413790}, 8) = 0 [pid 27720] rt_sigaction(SIGHUP, {SIG_IGN, [HUP], SA_RESTORER|SA_RESTART, 0x413790}, {SIG_DFL, [], 0}, 8) = 0 [pid 27720] rt_sigaction(SIGHUP, {0x402990, [HUP], SA_RESTORER|SA_RESTART, 0x413790}, {SIG_IGN, [HUP], SA_RESTORER|SA_RESTART, 0x413790}, 8) = 0 [pid 27720] rt_sigaction(SIGSEGV, {SIG_IGN, [SEGV], SA_RESTORER|SA_RESTART, 0x413790}, {SIG_DFL, [], 0}, 8) = 0 [pid 27720] rt_sigaction(SIGSEGV, {0x402990, [SEGV], SA_RESTORER|SA_RESTART, 0x413790}, {SIG_IGN, [SEGV], SA_RESTORER|SA_RESTART, 0x413790}, 8) = 0 [pid 27720] rt_sigaction(SIGBUS, {SIG_IGN, [BUS], SA_RESTORER|SA_RESTART, 0x413790}, {SIG_DFL, [], 0}, 8) = 0 [pid 27720] rt_sigaction(SIGBUS, {0x402990, [BUS], SA_RESTORER|SA_RESTART, 0x413790}, {SIG_IGN, [BUS], SA_RESTORER|SA_RESTART, 0x413790}, 8) = 0 [pid 27720] stat("/usr/libexec/gcc/sh-superh-linux/real-ld", 0x7fff7f2da820) = -1 ENOENT (No such file or directory) [pid 27720] stat("/usr/lib/gcc/sh-superh-linux/real-ld", 0x7fff7f2da820) = -1 ENOENT (No such file or directory) [pid 27720] stat("/home/koorogi/projects/aboriginal/build/simple-cross-compiler-sh4/lib/../sh-superh-linux/bin/real-ld", 0x7fff7f2da820) = -1 ENOENT (No such file or directory) [pid 27720] stat("/usr/libexec/gcc/sh-superh-linux/collect-ld", 0x7fff7f2da820) = -1 ENOENT (No such file or directory) [pid 27720] stat("/usr/lib/gcc/sh-superh-linux/collect-ld", 0x7fff7f2da820) = -1 ENOENT (No such file or directory) [pid 27720] stat("/home/koorogi/projects/aboriginal/build/simple-cross-compiler-sh4/lib/../sh-superh-linux/bin/collect-ld", 0x7fff7f2da820) = -1 ENOENT (No such file or directory) [pid 27720] stat("/usr/libexec/gcc/sh-superh-linux/ld", {st_mode=S_IFREG|0755, st_size=4746880, ...}) = 0 [pid 27720] access("/usr/libexec/gcc/sh-superh-linux/ld", X_OK) = 0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From koorogi at koorogi.info Mon Jan 6 02:58:35 2014 From: koorogi at koorogi.info (Bobby Bingham) Date: Sun, 5 Jan 2014 20:58:35 -0600 Subject: [Aboriginal] Build error when system has a cross compiler already In-Reply-To: <20140105213446.GA25364@duality.lan> References: <20140105082227.GA1957@duality.lan> <52C98E28.1040404@landley.net> <20140105213446.GA25364@duality.lan> Message-ID: <20140106025834.GB25364@duality.lan> On Sun, Jan 05, 2014 at 03:34:46PM -0600, Bobby Bingham wrote: > [...] > Now, I still have to see if I can figure out where this fixed set of > directories is coming from ... > Looks like it's literally hardcoded. See the attached patch, which fixes it for me, and from my (admittedly limited) testing, doesn't seem to cause any new problems. -- Bobby Bingham -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc-core-stopdefaults2.patch Type: text/x-diff Size: 1223 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From mattcampbell at pobox.com Mon Jan 6 14:36:57 2014 From: mattcampbell at pobox.com (Matt Campbell) Date: Mon, 06 Jan 2014 08:36:57 -0600 Subject: [Aboriginal] pkgsrc Message-ID: <52CABF89.7050601@pobox.com> I decided to try bootstrapping pkgsrc 2013Q4 on Aboriginal 1.2.6 (i686), and the bootstrap script failed while trying to run the test suite for bmake. Here's the relevant output: /root/pkgsrc/bootstrap/work/bmake/bootstrap.Linux/bmake -f Makefile > test.out 2>&1 /usr/bin/diff -u /root/pkgsrc/bootstrap/work/bmake/unit-tests/test.exp test.out --- /root/pkgsrc/bootstrap/work/bmake/unit-tests/test.exp +++ test.out @@ -75,11 +75,11 @@ shared.2.1 shared.2.99 shared.2.99 +cycle.1.99 +cycle.1.99 make: Graph cycles through `cycle.2.99' make: Graph cycles through `cycle.2.98' make: Graph cycles through `cycle.2.97' -cycle.1.99 -cycle.1.99 .for with :S;... OK b2af338b 3360ac65 *** Error code 1 Does anyone know what's happening here? Matt 1389019017.0 From rob at landley.net Wed Jan 8 18:16:39 2014 From: rob at landley.net (Rob Landley) Date: Wed, 08 Jan 2014 12:16:39 -0600 Subject: [Aboriginal] pkgsrc In-Reply-To: <52CABF89.7050601@pobox.com> References: <52CABF89.7050601@pobox.com> Message-ID: <52CD9607.6000106@landley.net> On 01/06/14 08:36, Matt Campbell wrote: > I decided to try bootstrapping pkgsrc 2013Q4 on Aboriginal 1.2.6 (i686), > and the bootstrap script failed while trying to run the test suite for > bmake. Here's the relevant output: > > /root/pkgsrc/bootstrap/work/bmake/bootstrap.Linux/bmake -f Makefile > > test.out 2>&1 > /usr/bin/diff -u /root/pkgsrc/bootstrap/work/bmake/unit-tests/test.exp > test.out > --- /root/pkgsrc/bootstrap/work/bmake/unit-tests/test.exp > +++ test.out > @@ -75,11 +75,11 @@ > shared.2.1 > shared.2.99 > shared.2.99 > +cycle.1.99 > +cycle.1.99 > make: Graph cycles through `cycle.2.99' > make: Graph cycles through `cycle.2.98' > make: Graph cycles through `cycle.2.97' > -cycle.1.99 > -cycle.1.99 > .for with :S;... OK > b2af338b > 3360ac65 > *** Error code 1 > > Does anyone know what's happening here? Not a clue, I'm afraid. Is the error perhaps further up in the output? I have three important pending todo items for aboriginal that are time-critical-ish: 1) Package upgrades (kernel -rc7 is out so it's that time again, and there's a new busybox as well). This drives aboriginal quarterly releases, new kernel means new aboriginal using it. 2) ccwrap write to use musl-libc.org. Probably not going to switch the architectures over gradually one at a time (especially since there's no support for sh4 or sparc in musl yet, at least last I checked). 3) bootstrap ellcc.org which builds an llvm toolchain, and does so using its own scripts so it doesn't require cmake. (Thus the inability of cmake to build with the existing uClibc++ is moot. :) I've got a bucket of other todo items, like trying Gentoo's bootstrap-rap script (curently it hiccups on a ccwrap thing, the rewrite should take care of that), switching the lfs-bootstrap to 7.4 and doing a blfs-7.4 subset script, rearchitecting the simple-root-filesystem/root-filesystem split so the first populates initramfs (using initmpfs) and the second is a single mount point under that (/usr/cc maybe) that has a setup script that adds symlinks to the host system's /bin and /lib directories so it all works... I've gotten sidetracked by rewriting the record-commands code so it's more or less a separate project (like it is in on the target system now), except that disentangling it from the host turns out to be a bit elaborate because the current path setup logic is... complicated. I also got sidetracked trying to replace bash with busybox ash: the resulting system boots, but building linux from scratch under it dies in setup when it sees "set +h" and goes "illegal option", and then when I patch it not to do that it dies trying to build the first package with a page of errors. So... not quite there yet, and I'm not spending time trying to fix busybox. I'll have to revisit this when I do toysh. Rob 1389204999.0 From koorogi at koorogi.info Wed Jan 8 23:53:16 2014 From: koorogi at koorogi.info (Bobby Bingham) Date: Wed, 8 Jan 2014 17:53:16 -0600 Subject: [Aboriginal] pkgsrc In-Reply-To: <52CD9607.6000106@landley.net> References: <52CABF89.7050601@pobox.com> <52CD9607.6000106@landley.net> Message-ID: <20140108235316.GA10213@duality.lan> On Wed, Jan 08, 2014 at 12:16:39PM -0600, Rob Landley wrote: > 2) ccwrap write to use musl-libc.org. Probably not going to switch the > architectures over gradually one at a time (especially since there's no > support for sh4 or sparc in musl yet, at least last I checked). FWIW, I'm working on an sh4 port of musl, and having aboriginal support musl would make my testing of the port easier. -- Bobby Bingham -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: