[Toybox] [PATCH] Support HOSTCFLAGS on musl

[orc]

On Thu, 14 Jun 2012 15:33:51 -0500
Rob Landley <rob at landley.net> wrote:

> On 06/14/2012 04:04 AM, orc wrote:
> >> And crypt.h exists because you only get crypt() defined out of
> >> that if you #define a feature test macro nobody ever uses.
> >> (Feature test macros in standard C headers: still an EPICALLY
> >> STUPID IDEA.)
> > 
> > I agree. Btw "sed -i '/<crypt.h>/d' ..." recursively on other
> > projects solves this. Or I can create crypt.h with one line:
> > "#include <unistd.h>"? (This can be stupid, I know)
> 
> Except that #including unistd.h by itself does _not_ give you crypt()
> unless you #define the macro, and if you've already included unistd.h
> earlier _without_ said macro, the re-include will be a NOP due to the
> header guards.

ah, I got it. This feature test macros really makes me mad sometimes :-)

> 
> The right fix to all this is for me to get a musl toolchain set up,
> but unlike the uClibc toolchains I built the musl one refuses to
> cross-compile unless I install it as root onto the host, because the
> wrapper tries to read a spec file at an absolute path;
> 
> landley at brillig:~/toybox/toybox$ CC=gcc CROSS_COMPILE=musl- \
>   CFLAGS=--static PATH=~/musl/tools:$PATH make
> scripts/make.sh
> Extract configuration information from toys/*.c files...
> Generate headers from toys/*.c...
> Extract help text from Config.in.
> Make generated/config.h from .config.
> Library probe...
> Compile toybox...
> gcc: /usr/local/musl/lib/musl-gcc.specs: No such file or directory
> make: *** [toybox] Error 1
> landley at brillig:~/toybox/toybox$
> 
> Looks like I need to adapt my ccwrap.c wrapper to musl, I just haven't
> gotten around to it yet...

I think issue with wrong spec path can be resolved with
--prefix=/path/where/to/install/musl --syslibdir='$(prefix)/lib' args
passed to musl's configure. (I think CC also should be set to musl-gcc
while building, but not CROSS_COMPILE, since musl-gcc is quite
standalone wrapper without things like musl-ar, musl-ld, etc. in $PATH,
you know that triplets dance better than I :-) ).
I just install musl on host temporarily in /tmp for quick tests, for
long-time tests I already have a set of custom scripts to (quickly)*
bootstrap a musl-enabled system for use in qemu.

* Since gcc is not assumed to be "quickly bootstrapped".

> Sometimes I try again. I've resubmitted the perl removal patches to
> linux-kernel a half dozen times over the years. (Doing so again is on
> my todo list, but it's not like I haven't made 'em public. The
> sources/patches/linux-*.patch files in the aboriginal linux mercurial
> repository, it's on the web...)

I've already got that patches from.. eh, bootstrap or sabotage.
They are floating around. Got bzImage in minimal system with only
busybox, busybox's ash as bash, gcc+binutils and musl as primary libc
for everything, yay! (Hm, I see they're updated)

> 
> Rob

 1339708605.0