From: Rene Rivera (grafik.list_at_[hidden])
Date: 2004-02-02 16:13:45
> So, after grabbing the newest gcc-tools.jam I was able to successfully
> override GCC and GXX, thanks!
> The next problem is that I see that the Boost tools are postprocessing
> the .o's with objcopy (not quite sure what that's about).
It's about working around a "bug" in the GNU linker which uses an n^2 algo for
merging debug symbols. The objcopy has the effect of disabling the invocation
of that algo, and reduces link times by 2 orders of magnitude.
> But, of
> course, I need to override this to use my version of objcopy and not
> the hardcoded one at /usr/bin/objcopy. Simply using
> -sOBJDIR=<my-objdir> doesn't work.
Yep. You'll have to either modify the toolset yourself (or wait until I change
to allow you to change the command). Or create another toolset that is based
on the gcc one specifically to change the actions (look at
gcc-stlport-tools.jam for some ideas on that).
> Also, if Boost needs ar to build I'll need to be able to override that
> as well.
I don't remember if this is overrideable already or not.
> Do you really have to write special-case code for each of these values
> in the jamfiles in order to allow the command line to override them?
Yes, in one way or another. Problem is that there are many ways that compilers
are "installed". GCC is especially bad, as *nix distributions many times use
custom installations. So we only account for the most common or default cases.
And hope to provide enough flexibility to allow for more. Of course we only
know how flexible it needs to be when people ask to make it work with their
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk