On Thu, 14 Jun 2012 15:33:51 -0500 Rob Landley <r...@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@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@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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net