[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: default $(libdir) and bi-arch systems

From: Eric Blake
Subject: Re: default $(libdir) and bi-arch systems
Date: Tue, 09 Sep 2008 19:57:01 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080708 Thunderbird/ Mnenhy/

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 64-bit mode object files, and
>>   - 64-bit mode object files are installed in /usr/lib64 or /usr/lib/64,
>>     not in /usr/lib ?
> 1. This proposal mixes configuration and packaging/system-integration
> (CPPFLAGS, changing libdir). Better leave packaging (such as  choosing
> CPPFLAGS, libdir) to system-integrators. Whatever you choose, will
> always be wrong (and potentially collide) somewhere.

This proposal did not mention changing CPPFLAGS.  Rather, it mentioned
conditionally changing the default for --libdir, and still allows the user
to override --libdir it according to his needs.

> 2. Linux systems using lib rsp. lib64 are "just special cases" of a much
> wider set of scenarios. At least some aspects of you wanting to exclude
> cross-compilation probably originates from this, because "multi-libing"
> is pretty common on embedded systems.

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 BEST place
to fix this is in various files (the logic for determining
whether a build is using a 64-bit compiler, and thus whether it should
install into lib64, is best relegated to the platform-specific file).
Even a patch to the manual to mention how such a should look
would go a long way.  But too many system integrators are not aware of the
need to install sane files.  I guess this proposal boils down
to whether it makes sense to have Autoconf help out in this case by
changing the defaults without needing to do so.

> 3. libdir/choosing compiler flags is not related to multi-arching
> (having several instances of runtime-libs installed in parallel), it is
> "multi-libing" (installing several instances of devel/link-libs in
> parallel).
> 4. CPPFLAGS is not necessarily the appropriate place to set up compiler
> flags for multilibs. In general, you will want either to set CFLAGS or
> even override CC.

Again, counterpoints 3 and 4 are irrelevant to the proposal - Bruno was
not asking that autoconf change compiler flags based on architecture, but
that it change installation locations based on snooping existing compiler
flags.  I'm interested in seeing a patch along the lines Bruno is
suggesting, and think it has a chance of being favorably reviewed,
although it won't make it into the 2.63 release.  But I don't have much
experience with multilib platforms myself, so I probably won't be writing
the patch.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]