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