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

Re: Multiarch in Debian unstable

On 2011-06-27 15:42:47 +0100, Steve Langasek wrote:
> On Mon, Jun 27, 2011 at 03:31:24PM +0200, Vincent Lefevre wrote:
> > How libraries are searched is not clear, but depending on how this
> > is done, there may be compatibility issues when the user installs
> > software in his home directory, in case he or some tool installs
> > libraries in $prefix/lib instead of $prefix/lib/<arch>.
> > For instance, if all the default .../lib/<arch> directories have
> > the precedence over the .../lib directories listed in the user's
> > $LIBRARY_PATH, bad things can happen. This is the choice followed
> > by upstream GCC (lib64 directories have the precedence over the
> > user's lib directories), with the following consequence:
> >   http://gcc.gnu.org/ml/gcc-help/2010-11/msg00341.html
> This particular issue will not occur with multiarch, because /usr/lib/<arch>
> will never be a symlink to /usr/lib in the canonical implementation.

There will be the same issue if libraries are installed directly
in /usr/lib/<arch> (see below).

> As a practical matter, the runtime path will list all of the multiarch paths
> before all of the non-multiarch paths.

Like what upstream GCC does. So, this means that if I have LIBRARY_PATH
(and LD_LIBRARY_PATH) containing $HOME/lib, the library search path
would be something like:


and if there's a library installed in /usr/lib/<arch> (by the system)
and a more recent version in $HOME/lib (by some tool that doesn't
support multiarch or... [see below]), then that's the system version
that will be taken instead of the version installed by the user. So,
directories specified by $LIBRARY_PATH no longer necessarily have the
precedence over the default system directories. And the header will be
taken from $HOME/include; thus it will not correspond to the library.

> (It does this already today.)

No, it doesn't. Well, it may depend on the tool, but for instance,
with the dynamic linker, the search order is:


instead of:


(according to strace). I think this is the right solution to avoid
the problem mentioned above.

> > Related to that, will Linux support fat binaries[*] one day?
> I don't agree that this is related. :)

Installing fat binaries in prefix/lib/<arch> would be meaningless.
So, I'd think they would be installed in prefix/lib, with the problem
mentioned above.

Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Reply to: