On Sat, 2006-01-28 at 13:07 +1100, Greg Schafer wrote:
> Jeremy Huntwork wrote:
>
> > Isn't using -B to find libraries an abuse as well?
>
> Huh? Using a documented switch for a documented purpose?
> RTFM :-)
>
The purpose of the -B flag is to override GCC_EXEC_PREFIX, the path the
gcc driver uses to find its own components.
>From the info file
------------------------------------------------------------------------
`-BPREFIX'
This option specifies where to find the executables, libraries,
include files, and data files __of_the_compiler_itself__ .
The compiler driver program runs one or more of the subprograms
`cpp', `cc1', `as' and `ld'. It tries PREFIX as a prefix for each
program it tries to run, both with and without `MACHINE/VERSION/'
(*note Target Options::).
------------------------------------------------------------------------
When set it will
1: change the options passed to the c pre-procesor ( adds -isystem
PATH/include ) so it can find reqd gcc headers (and the fixed
includes)
2: use cc1, collect2 etc if found under PATH instead of the ones the gcc
driver would normally invoke
3: sets the location gcc will use for pulling in gcc startfiles
(crtbegin.o crtend.o)
4: Prepends PATH to the library search order (doesn't add PATH/lib ) so,
if the flag was used for its stated purpose, it will pull in libgcc
from that location.
As stated before, the -B flag causes issues for multilib builds because
it does not get modified by the multilib spec.
This is perfectly understandable, gcc only installs 1 set of binaries
regardless of whether it is multilib or not, and applying multilib path
changes to a _binary_ search path is plain wrong.
-B isn't meant to be used for setting library search path (that is -L's
job), though it performs this task soley because when used for its
documented purpose it needs to find libgcc.
Used in the case of LFS, all the above changes to standard compilation
do not affect the build,
1: we have no includes in /usr/lib/include, so the added
-isystem /usr/lib/include wont affect the
the c pre-processor
2: gcc will use the binaries it was built with, as we have no gcc
component binaries installed
under /usr/lib/
3: gcc will pull in the correct c-library startfiles, more by accident
than anything else as gcc would normally be using this set path to
find ITS startfiles (crtbegin.o and crtend.o)
4: and of course adds the path to the start of the library search path
(where the compiler would normally expect to find libgcc)
Consider the fact that the only thing that we want to accomplish is use
the correct startfiles.
If you look into the history of this issue, it is this problem that
needed to be solved.
-B/PATH was chosen by DIY as using -L/PATH, while causing the correct
libraries to be found during the link, did not set the location used to
retrieve the correct startfiles. (these were pulled in from /tools as
gcc uses the first set found following its standard search pattern)
The startfile_prefix_spec is provided to tell gcc where the c-library
startfiles live
If startfile_prefix_spec is set
1: if the c-library startfiles exist under the set directory, the
startfiles are linked in using the full path to the startfiles, and
the path is appended to the end of the library search order to
find the libraries associated with those startfiles (ie: the
c-libraries)
2: if there are no c-library startfiles under the location, the
startfiles are specified to the linker without a path specified
and no additional library search path is added
NOTE: the only gcc behaviour altered is linking, as opposed to -B which
alters include search paths, binary search paths ...
Using -B/PATH to set a library search path and the path to the
c-libraries startfiles is like driving a nail with the back of an axe.
It can do the job (in this case), but it is not its stated purpose, nor
the right tool for the job.
So the question to lfs-dev is
Which method do you want to use to link in the correct startfiles
1: misuse the -B flag, overriding GCC_EXEC_PREFIX and setting isystem et
al
2: set the location of the startfiles in the spec provided just for this
purpose.
Thoughts?
Best Regards
Ryan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
