This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Partial autoconf transition thoughts


On Thu, Jun 12, 2003 at 01:22:11PM +0200, Maciej W. Rozycki wrote:
> On 11 Jun 2003, Alexandre Oliva wrote:
> > >  Well, see how AM_INSTALL_LIBBFD is defined. ;-)
> > 
> > Presumably you're configuring with --enable-shared
> > --enable-install-libbfd.  I'd never done that :-)
> > 
> > Anyway, $(exec_prefix)/$(host_alias) is entirely pointless.
> > $(exec_prefix) is already supposed to be host-specific.
> 
>  But libbfd is target-specific, so you can't install it directly in

That sounds like an artificial limitation.  Maybe it works best in
single-target configuration, but I've been using it with --enable-targets=all
for the last year or two.

But in Real Life (tm) I've had to LART my binutils build scripts quite a
bit to convince my first cross-binutils to use my *one* libbfd (in /usr/lib).

> $exec_prefix.  As the result of the discussion I wrote of, the current
> approach was selected from two alternatives: 
> $exec_prefix/$host_alias/$target_alias/lib and
> $exec_prefix/$target_alias/$host_alias/lib.  Of coures neither
> $exec_prefix/lib nor $exec_prefix/$target_alias/lib can be used as they
> (may) hold other versions of libbfd and $exec_prefix/$host_alias cannot
> be, either, as it would work for a single target only. 

What's wrong with $exec_prefix/$target_alias/lib?  What "other" versions
of libbfd?



Again, $exec_prefix/lib works just fine here with --enable-targets=all'ed
binutils.

(Unfortunately the binutils *tools* are still configured for a single
target, which is why I put them into per-target directories.)


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