Re: [Toybox] [PATCH] Support HOSTCFLAGS on musl
On Wed, 20 Jun 2012 18:56:35 -0500 Rob Landley r...@landley.net wrote: On 06/19/2012 02:41 AM, orc wrote: Seems no, cc -o kconfig/mconf kconfig/mconf.c kconfig/zconf.tab.c \ kconfig/lxdialog/*.c -lcurses -DCURSES_LOC=ncurses.h \ -DKBUILD_NO_NLS=1 -DPROJECT_NAME=\ToyBox\ kconfig/mconf.c:274: error: 'PATH_MAX' undeclared here (not in a function) ... setting HOSTCC works, but HOSTCFLAGS still not passed to $CC, results in above when doing 'make menuconfig HOSTCFLAGS=-D_GNU_SOURCE'. Ok, with no patch, try: make distclean HOSTCC=cc --static make defconfig The --static flag gets applied to the compiler. Okay, I'm see now that I can apply any CFLAGS :-) (And then ripping out the old CCFLAGS stuff which apparently never got documented.) It seems easiest to just add the flags straight into the one variable since it gets expanded and reparsed for whitespace by the existing scripts. (Admittedly that means if you have path to hostcc with a space in it, it won't work, but that's already the case and nobody's complained...) But scripts are not called before cc called. make -n menuconfig shows on top of clean toybox-0.3.0: You're right, that's why commit 484 set hostcc if it isn't already set. Forgot that. Eventually when menuconfig gets redone the whole kconfig directory goes with it, and the new stuff should actually get built by a script like the rest of it. (Makefiles are not my friend.) And because of that I patched kconfig/Makefile directly, for setting HOSTCFLAGS at the menuconfig stage, without HOSTCFLAGS it fails due to feature test macros on musl. (There already was a mail about that and you answered 'Seems reasonable.', that one I've sent with attachment was the result of corrupted patch pasted into message. Are we talking about 'make menuconfig' failure or I missed something?) Upon further review I noticed that your patch only modified the kconfig stuff and not the build for scripts/install.c binary. The instlist binary is also built with the host compiler, and already had a different variable performing this function. So simply applying your patch would have made the code inconsistent. Your patch added three lines, but upon further review I thought I might be able to do it with only one line, and now I suspect i just need to add a FAQ entry to add the flags to HOSTCC and not add any code to the build scripts at all. I modified only kconfig, but you can always review and improve/reject changes. Just did not got that CFLAGS can be set with HOSTCC (many projects suggest to use CFLAGS). Now the issue with toybox configuring is solved. Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] Support HOSTCFLAGS on musl
On Thu, 14 Jun 2012 11:52:00 +1000 David Seikel onef...@gmail.com wrote: On Thu, 14 Jun 2012 01:30:33 +0800 orc o...@sibserver.ru wrote: On Wed, 13 Jun 2012 11:59:23 -0500 Rob Landley r...@landley.net wrote: On 06/13/2012 10:02 AM, orc wrote: Sorry for corrupted email. I've attached original patch here. Could you give me a name for the commit message, please? (I like to attribute patches properly.) Thanks, Rob Support kconfig HOSTCFLAGS Support HOSTCFLAGS environment variable for building kconfig on musl system (HOSTCFLAGS=-D_GNU_SOURCE) Rob asked for your name for the commit message, not the commit message. So that he can say who made the patch. I am sorry, I misunderstand that. Just 'orc'. ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] Support HOSTCFLAGS on musl
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 Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] Support HOSTCFLAGS on musl
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
Re: [Toybox] [PATCH] Support HOSTCFLAGS on musl
Sorry for corrupted email. I've attached original patch here. toybox-0.3.0-menuconfig-musl.patch Description: Binary data ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
