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. 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... >> Sigh. It's too bad we don't have an #ifndef variant for function >> prototypes or I'd just prototype the darn functions right there in >> toys.h myself since the standard _says_ what they are. >> >> I'm going to assume shadow.h/getspnam isn't causing you a problem? > > Nope. That crypt.h was one. Weird. >>> Also, no lex and yacc sources for pregenerated *_shipped in kconf >>> (this is not so necessary, but even busybox and linux kernel has >>> *.l and *.y on their places :-) ). >> >> As far as I'm concerned those are the preferred sources for >> modification. If I wind up changing them, I'll hack the shipped >> directly. I still vaguely plan to write a replacement for all the >> gplv2 kconfig stuff at some point, but "in awk" (while clever) isn't >> something I feel I can maintain or extend. :) > > Nevermind that previous request - if I really wanna hack them in > future, I will take sources from busybox-1.20.1. And you better replace > them as you said. Once upon a time I tried to push them upstream and got bikeshedding: http://lkml.indiana.edu/hypermail/linux/kernel/0707.1/1741.html This often happens when I try to push stuff upstream, I give them the "works fine for me" version, they complain about something, I shrug and move on. 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...) > misc: sorry for my bad English. No problem. Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
