adding custom CFLAGS

[Bernhard Fischer]

On Wed, Oct 18, 2006 at 12:24:53PM -0400, Rob Landley wrote:
>On Wednesday 18 October 2006 12:25 am, Larry Brigman wrote:
>> I have tracked down all my troubles to a tool chain issue.
>> In using 1.1.2 I was able to use a custom CFLAGS variable
>> that would allow me to point busybox to the cross compile tool
>> chain includes and libraries.
>> 
>> The current version does not allow these options.
>
>By "current version" to you mean 1.2.1, or svn?
>
>> How do I get that functionality back without reverting back
>> to the older version?
>
>Hmmm...  We added ":=" to avoid recalculating lots of check_gcc() macros 
>(which is PAINFULLY slow, and largely there so Bernhard can keep an old Tru64 
>system upright through various necromantic rituals).  Unfortunately, this is 

;) Well, i added the "hosttools" make target for Tru64, and i added the
check_cc and check_ld to
a) support several versions of gcc, each of which may support one flag
   but not another
b) to support folks that don't use gcc but other compilers

Those two latter additions are not really entangled with True64, just as
a sidenote.

The current (i.e. svn) Make stuff currently does bomb a) as well as b)
back to the stoneage, but i guess that's ok for a (re-)start of the
build infrastructure. (anyone ran hosttools or check recently?)


>overriding anything provided in environment variables, isn't it?

You can say
make EXTRA_CFLAGS="-my-fancy-flags" CROSS="i286-hurd-uclibc"

to use you i286-hurd-uclibc- cross toolchain that uses -my-fancy-flags
in addition to any pre-set flags (these would be empty for that cross
anyway, but still).
>
>Probably the easy thing to do at the moment is search for CFLAGS:= in 
>Rules.mak (line 55 in my copy) and add your flags there.  This sucks as a 
>solution, anybody else got a better suggestion?

In 1.2.x, we had EXTRA_CFLAGS (or CFLAGS_EXTRA, i keep forgetting)
there; See above
>
>Makefiles are evil.  I am _so_ glad this is not my problem anymore.  Denis 
>replaced this mess entirely, which means they'll be re-fixing old bugs for a 
>while but hopefully have a better general infrastructure now...

well, make check barfs on a couple of tests, misses to detect the
correct applet order, thinks that busybox and grep and pidof as well as
readlink and sed and seq and sort and unzip and uuencode et al are
built.

ls -l and ls -s produce different output (regression compared to 1.2.1)
than GNU coreutils's ls.

which(1) is broken (saving 84 bytes is a nice thing to have, but only
iff it still works afterwards;)

HTH,