[Toybox] [PATCH] Support HOSTCFLAGS on musl

Rob Landley rob at landley.net
Thu Jun 14 13:33:51 PDT 2012


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 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...

>> 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.

 1339706031.0


More information about the Toybox mailing list