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: 12 April 2001 21:58

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

  My comments are directed towards the default working of the binutils
install scheme, which *does* work.  I generally consider messing with 
any of the other options to be an invitation to breakage.  It may be for
just that reason that nobody's documented them in detail before; it would
generate an awful lot of extra support work for the gcc volunteers....

>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're mistaken; it does.  There *aren't* naming clashes with libs
or linker scripts because native libs and ld scripts get installed to
$prefix/lib and target libs and scripts get installed to 
$prefix/$target/lib.  Target-specific (ie. non-native) libs and scripts
are never be installed in $prefix/lib.  Likewise for headers, which live
in $prefix/include for native and $prefix/$target/include for cross.

  Where's the clash?

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

  Your co-worker is right.  These two were very carefully engineered to
work together; do you think the scheme could be that seriously broken
and nobody would have noticed?

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

  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:

" Prior to adding the 2nd and 3rd configure parameters, The host old
host gcc would find the xgcc newlib and binutils libraries and headers
before it's own. This crippled the host gcc. "

  That should *NOT* have happened.  Perhaps you mistakenly put
$prefix/$target/bin in your $PATH setting *before* $prefix/bin ?  That
is a known way of breaking everything in the world, and something that
indeed should be documented, since it seems to trip people up every now
and again, but it would always be a broken thing to do in the first
place.

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

  Check the file MAINTAINERS in the gcc or binutils distribution, as
appropriate.  If that doesn't help, ask on the appropriate mailing list.
But really, I don't think the problems you've had need fixing in the
configure scripts, but in the documentation.

         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


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