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:
$HOME/lib/<arch>
/usr/local/lib/<arch>
/lib/<arch>
/usr/lib/<arch>
$HOME/lib
/usr/local/lib
/lib
/usr/lib
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:
prefix1/lib/<arch>
prefix1/lib
prefix2/lib/<arch>
prefix2/lib
prefix3/lib/<arch>
prefix3/lib
instead of:
prefix1/lib/<arch>
prefix2/lib/<arch>
prefix3/lib/<arch>
prefix1/lib
prefix2/lib
prefix3/lib
(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: