Re: Multi-architecture installation

[William Burns <bburns at aeroflex dot com>]

David:

Your comments seem directed towards the --prefix option to the
exclusion of --includedir and --libdir. It is these second two that I
feel deserve a little more attention in the gcc and/or binutils
documentation.

The whole rambling chain of reason follows:

David Korn wrote:
> 
> >> >> ../src/configure --prefix=/usr/local
> >> >--includedir=/usr/local/gcc-2.95.2/include
> >> >--libdir=/usr/local/gcc-2.95.2/lib --with-gnu-as --with-gnu-ld
> >> >--target=mips4el-elf --with-newlib --enable-languages=c

-- --

>   Binutils doesn't have any way to keep different versions from
> clashing although it does follow the same scheme as gcc to keep different
> targets from clashing.

As far as I can tell, binutils only avoids naming clashes for
executables. Name conflicts exist between targets under the default
$prefix/lib directory. Shouldn't binutils also avoid naming clashes
for libraries (and possibly includes) by default?

>   You must remember to use the same --prefix (etc) settings for the
> binutils as you do for the gcc.  Otherwise they won't find each other
> properly.

Yup. Actually, I'm using a single configure script to build binutils,
gcc and newlib in one shot. That way I can't accidentally have a
different --prefix from one to the next.

>   The target specific executables are stored in two ways:  they are
> stored with a generic name in a target-specific directory (gcc in
> $prefix/$target/bin as mentioned above) and they are stored with target-
> specific names in a generic directory (/usr/local/bin will have gcc for
> the native compiler, target-gcc for cross compilers).  So there's no
> conflict; they either have different names or they live in different dir
> paths.

Again, this all works fine for the executables...

> >Whups. libopcodes.a is clearly target specific.
> >??? I thought that binutils and gcc appended the target name to any
> >file that was target specific. Isn't this a naming conflict that would
> >trip up a large number of people?

libcodes.a gets left out of this $prefix/$target scheme because it is
an archive (library) instead of an an executable program.
If I specify "configure --libdir $prefix/$target" to avoid naming
conflicts in binutils it works but is (slightly) annoying. The target
specific libraries in gcc which already have a
gcc-lib/$target/$version path get placed under $prefix/$target.
If I'm allowed to be nit-picky here, $target ends up in the path
twice.

Possibly if I abandon the single source-tree build, I can specify a
different --libdir for binutils like this:
"config --libdir $prefix/lib/gcc-lib/$target/$version"
That way, binutils and gcc *might* share a library directory. (I
haven't tried it)

Everything is working smoothly on my system right now, I'm just
bringing this up because it seems like the library/directory naming
convention could work more smoothly between binutils and xgcc. I was
initially told by a co-worker that I wouldn't have to worry about
*any* naming conflicts because it was so common to have multiple
cross-compilers installed in the same $prefix that *all* names that
might conflict in binutils, gcc and newlib would have $target appended
to either their file name or their directory path.

I was surprised to end up w/ a naming conflict and about the
difficulty that I had finding the --libdir option.
Changing the configure scripts for cross-binutils and/or xgcc so that
by default they both use common library and include directory paths
that include $target will probably save some other guy a lot of time.

Who is the maintainer for these configure scripts?, Do you know?

-Bill

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com