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

[Ralf Wildenhues]

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 
> ability to build/install for an "offset" directory that the rest of the 
> responsibility can fall into the hands of autoconf and automake.

There are several issues mentioned here.  Among them:

- using an "offset" directory.  Sounds a bit like $ORIGIN or other
relocatable technique to me.  For such functionality, libtool would
need quite a few adjustments.  Also, these relocation things are not
portable, so we need to be able to degrade gracefully on less able
systems/linkers.

- computing the default libdir.  I would be glad to see all autotools,
including libtool and gnulib's lib-link, use consistent default values.
The code should ideally not be duplicated though, which is quite certain
to prevent consistency.  Even more ideally, it should not be duplicated
among autotools and GCC either.  For other compilers, I don't currently
see much choice.

FWIW, I don't see any of the current proposals in this thread as
sufficient yet.  IIRC then only recent releases of GCC provided
the needed bits, and I'm not convinced it provides enough information
even now.

- several problem within libtool: current libtool simply compares
library directories by string comparison, without `../' and symlink
name removal.  A general solution to this is rather hard, if not
impossible to do without some assumptions.  I'm not saying this must be
solved fully, but libtool should work well with a new default libdir
computation.

For example, it should not add a run path just because the user
specified /usr/lib/../lib64 as installation directory for a library
rather than /usr/lib64.

- current libtool picks a .la file when it finds one, irrespective of
whether it is for the correct multilib flavor or the wrong one.  This
leads to the need to be very careful to never introduce the wrong
directory into its search path.  One way out would be to encode the
multilibness in the .la file.  Ugly, because it would be nice not to
have to make assumptions about the multilib flavors.

> There 
> would need to be a configure framework which knows about the "standard" 
> multilib conventions for each target and a build framework which builds 
> all of them (or just the ones desired). Libtool is already complex enough 
> so I think that most of the responsibility should be outside of libtool.  
> Libtool needs to know how to store multilib objects/libraries in the 
> build tree (perhaps via a user provided 'tag') , and how to install the 
> correct ones when requested.

Agreed: it would be good if this knowledge were not replicated inside
libtool's primary sources, as it certainly is not a feature that is
needed solely when you create libraries.  This isn't much of a question
of how complex libtool is already, but of code orthogonality.

To summarize, I don't think all these issues need to be addressed, or
addressed at the same time, but if non-canonicalized paths are to be the
default then libtool needs a bit of help at least.

Cheers,
Ralf