On 2011-06-28 09:54:34 +0100, Steve Langasek wrote:
> On Tue, Jun 28, 2011 at 02:05:05AM +0200, Vincent Lefevre wrote:
> > > > 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).
>
> No, it's not the *same* issue. The issue you referenced is /usr/lib taking
> precedence over /usr/local/lib because of /usr/lib64 being a symlink.
No, the real problem is that /usr/lib64 takes the precedence over
/usr/local/lib (with upstream's GCC). Note that if /usr/lib64 were
a real directory, the library should have been installed directly
in /usr/lib64 and the problem would be the same.
> In multiarch, /usr/local/lib still takes precedence over /usr/lib.
OK.
> */usr/lib/$arch* might take precedence over /usr/local/lib, and
> that's not desirable, but it's not the same issue.
If /usr/lib/$arch takes precedence over /usr/local/lib, that's the
same class of problem: an arch-specific directory takes precedence
over all the conventional lib directories specified in the path.
> > > 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
>
> Huh? Certainly not. Why would you expect gcc to look in $HOME/lib/<arch>
> if you haven't put $HOME/lib/<arch> in your LIBRARY_PATH? gcc isn't going
> to magically append the architecture to all directories in the search path.
Well, upstream GCC does search prefix/lib64 even if $LIBRARY_PATH
contains only prefix/lib.
The specifications should be very clear about:
* in the (ordered) list of directories in which the libraries will
be searched (by static and dynamic linkers), depending on the
value of LIBRARY_PATH and LD_LIBRARY_PATH;
* the directory in which the libraries should be installed by
development tools.
> with LIBRARY_PATH=$HOME/lib, the build-time order would (currently) be:
>
> $HOME/lib
> /usr/x86_64-linux-gnu/lib
> /usr/lib/x86_64-linux-gnu
> /lib
> /usr/lib
>
> (via:
> gcc -print-search-dirs | sed -n -e's/^libraries: =//p' | sed -e's/:/\n/g' |
> xargs -n1 readlink -f)
>
> So at build time, there doesn't appear to be an issue.
That's with Debian's GCC.
The upstream version behaves differently: it first includes all the
lib64 variants (which is bad, IMHO). For instance, with
LIBRARY_PATH=/home/vlefevre/gmp/athlon64/lib:/home/vlefevre/x86_64/lib
I got:
/home/vlefevre/gmp/athlon64/lib/x86_64-unknown-linux-gnu/4.3.1/
/home/vlefevre/gmp/athlon64/lib/../lib64/
/home/vlefevre/x86_64/lib/x86_64-unknown-linux-gnu/4.3.1/
/home/vlefevre/x86_64/lib/../lib64/
/usr/local/stow/gcc-4.3.1/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/
/usr/local/stow/gcc-4.3.1/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../x86_64-unknown-linux-gnu/lib/x86_64-unknown-linux-gnu/4.3.1/
/usr/local/stow/gcc-4.3.1/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../x86_64-unknown-linux-gnu/lib/../lib64/
/usr/local/stow/gcc-4.3.1/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../x86_64-unknown-linux-gnu/4.3.1/
/usr/local/stow/gcc-4.3.1/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../lib64/
/lib/x86_64-unknown-linux-gnu/4.3.1/
/lib/../lib64/
/usr/lib/x86_64-unknown-linux-gnu/4.3.1/
/usr/lib/../lib64/
/home/vlefevre/gmp/athlon64/lib/
/home/vlefevre/x86_64/lib/
/usr/local/stow/gcc-4.3.1/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../x86_64-unknown-linux-gnu/lib/
/usr/local/stow/gcc-4.3.1/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../
/lib/
/usr/lib/
BTW, that's a completely different problem, but I wonder why GCC
(Debian's and upstream) no longer includes /usr/local/lib, while
cpp has /usr/local/include in its search path. This doesn't seem
to be consistent.
> > > (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.
>
> Ok - I didn't think we had this right, but it's great to know that we do.
--
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/20110628133545.gc17...@prunille.vinc17.org
