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

Re: Multiarch in Debian unstable

On Mon, Jun 27, 2011 at 03:31:24PM +0200, Vincent Lefevre wrote:
> On 2011-06-27 11:54:53 +0100, Steve Langasek wrote:
> > Work is ongoing to formulate a proper, distribution-neutral interface for
> > querying the correct multiarch path for a system.  In the meantime, if you
> > are an upstream affected by this issue, or a maintainer of a package whose
> > upstream is affected, you are welcome to join us in discussing these matters
> > on debian-devel as well.

> > A summary of currently known upstream compatibility issues, and the status
> > of prospective patches for them, can also be found in the Debian wiki here:

> >   http://wiki.debian.org/Multiarch/TheCaseForMultiarch#Impact

> Just a comment...

> 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.  A user
could do this locally, but there's no good reason to ever do so.

As a practical matter, the runtime path will list all of the multiarch paths
before all of the non-multiarch paths.  (It does this already today.)  If
nothing else, we do need to list out these directories in /etc/ld.so.conf.d
(because other things parse these files), and it's impractical to have a
different config file for each of the multiarch paths for each architecture.

> Related to that, will Linux support fat binaries[*] one day?

I don't agree that this is related. :)

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Reply to: