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

[Eric Blake]

-----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 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 config.site 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 config.site should look
would go a long way.  But too many system integrators are not aware of the
need to install sane config.site 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 config.site 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjHKW0ACgkQ84KuGfSFAYDfUQCfcm16z+nhCIembpc5h1K72D/+
8zcAoKNXlEyrcM2gEfKxcf8kIiWqSsZL
=WNQw
-----END PGP SIGNATURE-----