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 <vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110628000505.ga17...@prunille.vinc17.org
