Hello,
* Bob Friesenhahn wrote on Wed, Sep 10, 2008 at 06:26:34PM CEST:
>
> Multilib support via libtool has been on the wish list for quite a while
> but implementing it is either a Big Job for libtool, or for the build
> environments which drive it. It seems to me that if libtool supports the
On Wed, 10 Sep 2008, Bruno Haible wrote:
Right. There is also value to separate between some libraries which
use the same ABI but with different run-time behavior. For example,
libraries instrumented for profiling could go in a different
directory.
Sure, there are several use-cases:
1) Ther
> Some care needs to be taken, though, because the gcc compiler on MacOS X 10.5
> (which produces 32-bit code by default) is configured like this:
>
> $ gcc -print-multi-os-directory
> .
> $ gcc -print-multi-os-directory -m64
> x86_64
> $ gcc -print-multi-os-directory -m32
> .
> $ gcc -print-mult
> How about changing the libdir default (currently $exec_prefix/lib) to be
> $exec_prefix/lib64 or $exec_prefix/lib/64, respectively, when
> - not cross-compiling, and
> - $CC $CPPFLAGS generates 64-bit mode object files, and
> - 64-bit mode object files are installed in /usr/lib64 or /usr/l
Paolo Bonzini wrote:
> I think the right way would be to set the libdir default to
>
> $exec_prefix/lib/`$CC -print-multi-os-directory $CFLAGS $CPPFLAGS`
Thanks for mentioning -print-multi-os-directory; it is currently undocumented
but appears to fit the bill on Linux/x86_64 machines:
$ gcc -pri
Bob Friesenhahn wrote:
> There is no shortage of reasons to want to put libraries in different
> directories and autoconf/libtool should not stand in the way of
> freedom.
The proposal is to change the _default_ value of $(libdir). The --libdir
option still gives the user full freedom.
> > The
Ralf Corsepius <[EMAIL PROTECTED]> writes:
> On Tue, 2008-09-09 at 20:07 -0700, Russ Allbery wrote:
>> I happened to be looking at this just today and ended up adopting the
>> following solution when adding library search paths for third-party
>> libraries.
> Well, this is limited to distinguishi
On Wed, 10 Sep 2008, Ralf Corsepius wrote:
Yes, I agree that there are more than just Linux and Solaris scenarios
that would be worth supporting, if it is easy to maintain.
The fundamental oversight in this proposal is the desire to wanting to
distinguish 64bit and 32bit systems. multilibing ac
On Tue, 2008-09-09 at 20:07 -0700, Russ Allbery wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> > This is non-applicable, because there is no general rule to distinguish
> > "64bit compiler flags from 32bit compiler flags", nor any hard-coded
> > rule to which multisubdir a compiler might
Ralf Corsepius <[EMAIL PROTECTED]> writes:
> This is non-applicable, because there is no general rule to distinguish
> "64bit compiler flags from 32bit compiler flags", nor any hard-coded
> rule to which multisubdir a compiler might be using.
>
> I.e. an approach trying to snoop for -m32/-m64 woul
On Tue, 2008-09-09 at 19:57 -0600, Eric Blake wrote:
> >> How about changing the libdir default (currently $exec_prefix/lib) to be
> >> $exec_prefix/lib64 or $exec_prefix/lib/64, respectively, when
> >> - not cross-compiling, and
> >> - $CC $CPPFLAGS generates 64-bit mode object files, and
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Corsepius on 9/9/2008 7:30 PM:
>> How about changing the libdir default (currently $exec_prefix/lib) to be
>> $exec_prefix/lib64 or $exec_prefix/lib/64, respectively, when
>> - not cross-compiling, and
>> - $CC $CPPFLAGS generates
On Wed, 2008-09-10 at 01:00 +0200, Bruno Haible wrote:
> Hi,
> But when people configure GNU packages built with autoconf in 64-bit mode,
> "make install" will by default install the libraries in $prefix/lib. This
> leads to two problems:
> 1) If the user has already installed 32-bit libraries
13 matches
Mail list logo
