[Toybox] [PATCH] Support HOSTCFLAGS on musl

[Rob Landley]

On 06/19/2012 02:41 AM, orc wrote:
> On Mon, 18 Jun 2012 11:23:10 -0500
> Rob Landley <rob at landley.net> wrote:
> 
>> On 06/14/2012 03:50 AM, orc wrote:
>>> On Thu, 14 Jun 2012 11:52:00 +1000
>>> David Seikel <onefang at gmail.com> wrote:
>>>
>>>> On Thu, 14 Jun 2012 01:30:33 +0800 orc <orc at sibserver.ru> wrote:
>>>>
>>>>> On Wed, 13 Jun 2012 11:59:23 -0500
>>>>> Rob Landley <rob at 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'.
>>
>> Sorry for the delay, the weekend got away from me.
>>
>> I noticed I already have a "CCFLAGS" (from 2007) being applied to
>> $HOSTCC for building install.c in both Makefile and
>> scripts/install.sh. It's not being used for the HOSTCC invocations in
>> kconfig, and it seems to me that means I'm doing it wrong.
>>
>> Is this a reasonable equivalent to your patch?
>>
>> --- a/configure	Sat Jun 16 15:16:08 2012 -0500
>> +++ b/configure	Mon Jun 18 11:16:01 2012 -0500
>> @@ -11,3 +11,4 @@
>>  [ -z "$CC" ] && CC=cc
>>  [ -z "$STRIP" ] && STRIP=strip
>>  [ -z "$HOSTCC" ] && HOSTCC=gcc
>> +HOSTCC="$HOSTCC $HOSTCFLAGS"
> 
> 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.

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

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.

 1340236595.0