-----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 ebb9@xxxxxxx -----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----- _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
