This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Multi-architecture installation


>-----Original Message-----
>From: William Burns [mailto:bburns@aeroflex.com]
>Sent: 16 April 2001 16:57

 [ Apologies for taking so long to reply; been working way hard this week. ]

>>   Where's the clash?
>
>ar -t /$target/lib/libopcodes.a
>This shows a "disassemble.o" in the archive. What processor should it
>be dissasembling for?
>Possibly I've jumped to the conclusion that libopcodes.a will be
>overwritten by another binutils. Maybe the next binutils just adds to
>the existing libopcodes.a?

  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 ?

  This is a native library for dealing with opcodes.  Which CPU will
it disassemble for ?  Any cpu for which it contains modules named *-dis.o
and *-opc.o (or similar).  Why is it not a problem to install a new one
on top?

  Well, up to now I haven't been interested enough in the inner workings of
binutils to care; I've just ploughed ahead and built and installed 
different cross toolchains, never had any trouble and never cared.  But
you've prompted me to find out, and it can be explained very very simply:

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

  I should explain that statement.  libopcodes.a is of course used in the
course of building utilities such as objdump.  When you build binutils for
target X, you get a X-objdump that has been linked with the libopcodes and
libbfd in the same build tree, which both contain code to diassemble for
target X.  When you later come to build for target Y, you get a Y-objdump,
that has been statically linked NOT with the target-X-libopcodes in
/usr/local/lib, but with the newly built target-Y-libopcodes in the cross
binutils build tree.  Then at the time of installing target-Y binutils,
the target-X-libopcodes in /usr/local/lib gets overwritten.  But nobody
cares because nobody uses it.  The libopcodes.a that gets installed is
not used by any of the Gnu software.

  If you were writing your own tools that interface with binutils, you
certainly would find this a problem; after installing target-Y, you would
no longer have a target-X-libopcodes to link your custom target-X tools
against.  That's why libopcodes, libbfd et al. are distributed with the
binutils code and built at the same time.  You'd have to make your tools
part of the binutils dir. tree.  However, that's not what you're doing,
and you won't have any problems when your libopcodes gets overwritten.  If
you don't believe me, try it.  I did, just now:  I installed an m68k-elf
binutils on top of my existing native and ppc binutils, and all three work.

  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...

>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.  It does install
libraries in /usr/local/lib/gcc-lib/$target/$gcc-version.  Your native gcc
should not be searching any directory that has '$target' in its name.  So I
think you either haven't understood the exact nature of the problem, or
haven't explained it well enough for me to understand.  To try and cut
through this a bit, try running your host gcc as 

  gcc -print-search-dirs

and post the output it prints here; we'll take a look at whether it makes
sense or not.  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?

        DaveK
-- 
"screams erupted at a Seattle hotel where Microsoft founder Bill Gates was
addressing an education and technology conference. He was whisked away as
his audience bolted for the exits. Some audience members were knocked down
by others trying to get out."
       -- CNN 2/28/01

>To: David Korn
>Cc: crossgcc@sourceware.cygnus.com
>Subject: Re: Multi-architecture installation
>
>
>
>>   If anything has gone wrong with your system, I suspect that it's
>> down to a problem with your custom Aeroflex method of building and
>> installing.  You mentioned in one of your earlier mails:
>...
>
>
>
>> But really, I don't think the problems you've had need fixing in the
>> configure scripts, but in the documentation.
>
>
>Ok.
>
>-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
>


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]