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

[Ralf Corsepius]

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
> >>   - 64-bit mode object files are installed in /usr/lib64 or /usr/lib/64,
> >>     not in /usr/lib ?

> > 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 fundamental oversight in this proposal is the desire to wanting to
distinguish 64bit and 32bit systems. multilibing actually is about
supporting several ABIs in parallel. 

64/32 bit ABIs on Linux actually are a very special case.

>   The BEST place
> to fix this is in various config.site files
Well, IMO, config.site is not an appropriate place for these kind of
scenarios, because it isn't able to handle multilibs at all.

This deficiency has been the reason for me to discourage people from
applying config.site and for wishing upstream autoconf to let it die.

>  (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).
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 would be naive. 

If somebody you really wants to set up a "reasonable guess" at a "the
multi-subdir in effect", he would have to dig much deeper into a
compiler's internals.

> 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
OK, I miss-read this part of his posting.

>  - Bruno was
> not asking that autoconf change compiler flags based on architecture, but
> that it change installation locations based on snooping existing compiler
> flags.
This would be very difficult. Remember the lib64/lib issue libtool has
been suffering from for many years (AFAICT it still is) and has caused
Linux distribution vendors to apply hacks to libtool covering their
particular demands.

>   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,

I maintain ca. 10+ embedded GNU-toolchains and several 
Linux-><other system> cross GNU-toolchains ;)

Ralf