Telling gcc about the binutils

Telling gcc about the binutils

[Markus Klink]

Dear "List",

after I have installed egcs 1.03a on a Sparc Solaris, I discovered that my
installation was quite buggy. After this, I installed the binutils 2.9 but
unfortunately gcc still uses the old utils it finds somewhere else.
I changed my PATH in a way that egcs and the binutils are to be found
first. But it did not help.
After some grieving, I decided to do a complete reinstall (deleting
objdir, new configure etc.), but gcc still uses the old binaries.

How can I tell gcc and g++ to look for the binaries in a certain
directory?

Markus Klink
wissenschaftliche Hilfskraft
Sonderforschungsbereich 504, Universitaet Mannheim

Re: Telling gcc about the binutils

[Martin von Loewis]

> How can I tell gcc and g++ to look for the binaries in a certain
> directory?

You can't; gcc has a fixed search order for these:
1) Look in the installation directory
2) Look in the architecture binaries directory (/usr/sparc-sun-solarisxxx/bin)
3) Look elsewhere

From that, it is quite easy to make a specific installation use a
certain set of tools: Just put symlinks into the installation
directory (the one where cc1 and cc1plus live).

Technically, you can specify another such directory using the -b and
-B options.

On Sparc, there is also a difference whether you configure
--with-gnu-as or not. If you say nothing, it will always try
/usr/ccs/bin as the second step.

Hope this helps,
Martin

Re: Telling gcc about the binutils

[Jeffrey A Law]

  In message < Pine.LNX.3.96.980701095106.7760A-100000@mailhost.sfb504.uni-mannheim.de >you write:
  > after I have installed egcs 1.03a on a Sparc Solaris, I discovered that my
  > installation was quite buggy. After this, I installed the binutils 2.9 but
  > unfortunately gcc still uses the old utils it finds somewhere else.
  > I changed my PATH in a way that egcs and the binutils are to be found
  > first. But it did not help.
  > After some grieving, I decided to do a complete reinstall (deleting
  > objdir, new configure etc.), but gcc still uses the old binaries.
Use "gcc --print-search-dirs" to get a list of its internal search
paths.  Those are checked before consulting the user's path environment
variables.

Odds are there's old binutils in one of the internal search directories.

jeff

Search paths

[Carlo Wood]

| Use "gcc --print-search-dirs" to get a list of its internal search paths.

Interesting, didn't know about that one :)...
The order seems pretty messy though, it looks often in
directories that do not exist (but carry the version
of THIS particular snapshot/version).

programs:
/usr/local/egcs-cvs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.43/
/usr/local/egcs-cvs/lib/gcc-lib/i686-pc-linux-gnu/
/usr/lib/gcc/i686-pc-linux-gnu/egcs-2.91.43/

Why look in a directory that never was created?

/usr/lib/gcc/i686-pc-linux-gnu/
/usr/local/egcs-cvs/i686-pc-linux-gnu/bin/i686-pc-linux-gnu/egcs-2.91.43/

Twice a i686-pc-linux-gnu?  It doesn't exist either.

/usr/local/egcs-cvs/i686-pc-linux-gnu/bin/

Again huh?  Since "/usr/local/egcs-cvs" is my install
directory, this one should be in front of 
"/usr/lib/gcc/i686-pc-linux-gnu/egcs-2.91.43/"?

libraries:
/usr/local/egcs-cvs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.43/
/usr/lib/gcc/i686-pc-linux-gnu/egcs-2.91.43/

Why look in a directory that never was created?

/usr/local/egcs-cvs/i686-pc-linux-gnu/lib/i686-pc-linux-gnu/egcs-2.91.43/

Twice a i686-pc-linux-gnu?  It doesn't exist either.

/usr/local/egcs-cvs/i686-pc-linux-gnu/lib/
/usr/local/egcs-cvs/lib/i686-pc-linux-gnu/egcs-2.91.43/

Why look in a directory that never was created?

/usr/local/egcs-cvs/lib/
/lib/i686-pc-linux-gnu/egcs-2.91.43/

Why look in a directory that never was created?

/lib/
/usr/lib/i686-pc-linux-gnu/egcs-2.91.43/

Why look in a directory that never was created?

/usr/lib/


Me thinks that the search paths do need a face lift.

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>

Re: Search paths

[Carlo Wood]

|   > The order seems pretty messy though, it looks often in
|   > directories that do not exist (but carry the version
|   > of THIS particular snapshot/version).
| We can't even guess what might be going on since we don't know how
| you configured the toolchain.
| 
| Many directories are searched because they *may* contain things
| built by other packages like binutils, libg++, etc.  Just because
| a directory is empty in an egcs installation doesn't mean it's
| always empty.

They are not empty, they don't exist, and when they contain
the string "egcs-2.91.43/" then I doubt it will be created by
other packages like binutils, libg++, etc...

I hope you see my point now :), I didn't complain about any
directory that didn't contain the string "egcs-2.91.43/".

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>

Re: Search paths

[Jeffrey A Law]

  In message < 199807021533.RAA21650@jolan.ppro >you write:
  > | Use "gcc --print-search-dirs" to get a list of its internal search paths.
  > 
  > Interesting, didn't know about that one :)...
Don't feel bad -- I worked on the compiler for years before I new about
it.

  > The order seems pretty messy though, it looks often in
  > directories that do not exist (but carry the version
  > of THIS particular snapshot/version).
We can't even guess what might be going on since we don't know how
you configured the toolchain.

Many directories are searched because they *may* contain things
built by other packages like binutils, libg++, etc.  Just because
a directory is empty in an egcs installation doesn't mean it's
always empty.

Some paths come from compiler builtins derived from MD_EXEC_PREFIX
(which is necessary to find some system things like crt0), others
are derived from your configure arguments).  Depending on the exact
values, some searches of the same directory would be considered
normal.

  > Me thinks that the search paths do need a face lift.
Maybe.  I think you're taking an overly simplistic viewpoint of
how they're used.

jeff

Re: Search paths

[Robert Lipe]

Carlo Wood wrote:

[ non-obvious search paths ] 

I won't try to defend or explain any but one question you raised.

> /usr/local/egcs-cvs/i686-pc-linux-gnu/bin/i686-pc-linux-gnu/egcs-2.91.43/
> 
> Twice a i686-pc-linux-gnu?  It doesn't exist either.

If you think only native, it sounds silly.  If you think cross, it makes
more sense.   Just treat native as a degenerate case of cross and you get
the triple (quadruple) once for host, once for target.

Those of us that have the same source built on the same box for 
five different targets (some have more than I do) are *grateful* 
that there are host and target components in such pathnames...


RJL