Re: Multi-architecture installation

[William Burns <bburns at aeroflex dot com>]

David:

David Korn wrote:
> 
>  [ Apologies for taking so long to reply; been working way hard this week. ]


No problem. Thanks for all the time and attention that you've given.

> >ar -t /$target/lib/libopcodes.a
> >This shows a "disassemble.o" in the archive. What processor should it
> >be dissasembling for?
> 
>   First of all, I don't think you mean /$target/lib.  Perhaps you mean
> /usr/local/lib/libopcodes.a, which is the same thing as
> $prefix/lib/libopcodes.a ?


Yes, sorry... My mistake.

>   It doesn't matter what's in libopcodes.a.  That's because it is never
> used.


So I could blow away the contents of $prefix/lib/ and $prefix/include/
without effecting xgcc...

>   Seriously, do you really think it might be impossible to have more than
> one cross toolchain at a time and nobody would have noticed?  Ask Kai
> Ruottu on this list, he's probably got twenty or thirty cross toolchains
> on his system at any one time...


I was getting paranoid after several failed xgcc builds...

> >The problem there was the default set of directories that pre 2.95
> >versions of gcc check for libraries and headers. Installing an xgcc in
> >/usr/local caused the pre 2.95 host gcc to find the "/usr/local/lib"
> >xgcc libraries before it's own. W/ a host gcc that is version 2.95 or
> >later, there is no conflict.
> 
>   This explanation seems incorrect to me.  Installing a cross gcc in
> /usr/local shouldn't install anything in /usr/local/lib...


Looking at an old build...
$prefix/include contains machine, sys, assert.h, reent.h, etc.
I overlooked the fact that these are from newlib, not gcc.

We built newlib w/ the same --prefix parameter that we gave gcc
(/usr/local). Now that xgcc, binutils and newlib are getting built via
the same invocation of configure, the --includedir and --libdir
options are taking effect for binutils and newlib, moving their files
out of the "way" as well.

>   gcc -print-search-dirs


I did this before and the results didn't mention the /usr/local
directories. On the other hand, if i've got a "bad" xgcc/newlib
install, invoking the host gcc w/ a -I /usr/include produced different
(better) results than invoking gcc without -I.
I discovered this after doing some web searches turned up the issue.
After seeing it documented elsewhere, I didn't question the paradox
that the print-search-dirs output represented.
Here's a link:
http://list-archive.xemacs.org/xemacs-beta/199909/msg00186.html

Here's the output.
-- --
> $gcc -print-search-dirs
> install: /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/
> programs: /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/:/usr/lib/gcc-lib/i386-redhat-linux/:/usr/lib/gcc/i386-redhat-linux/egcs-2.91.66/:/usr/lib/gcc/i386-redhat-linux/:/usr/i386-redhat-linux/bin/i386-redhat-linux/egcs-2.91.66/:/usr/i386-redhat-linux/bin/
> libraries: /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/:/usr/lib/gcc/i386-redhat-linux/egcs-2.91.66/:/usr/i386-redhat-linux/lib/i386-redhat-linux/egcs-2.91.66/:/usr/i386-redhat-linux/lib/:/usr/lib/i386-redhat-linux/egcs-2.91.66/:/usr/lib/:/lib/i386-redhat-linux/egcs-2.91.66/:/lib/:/usr/lib/i386-redhat-linux/egcs-2.91.66/:/usr/lib/
-- --

> ...  Is it possibly the case that the old host gcc was built
> according to the procedures invented by your Colorado site, with a non
> standard set of directory paths configured into it?


The host gcc is the standard one distributed w/ RedHat 6.1
(egcs-1.1.2-24). What RedHat might have done to it I can't say.

-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