Hi Matthias,
On Wed, Jun 01, 2011 at 12:03:36AM +0200, Matthias Klose wrote:
> >Some time ago I asked Steve Langasek to verify what output of:
> >
> >$ gcc -v /dev/null |& grep ^LIBRARY_PATH
> >
> >will return on the multiarch system. Basically, cmake parses it and loads
> >implicit link directories from it. I would prefer if both /lib/{triplet} and
> >/usr/lib/{triplet} were in that list so I could go with proper implementation
> >from there. However, at the moment, I don't know what's the status of this in
> >gcc. AFAIK, Ubuntu gcc returns some inconsistent paths. All I need is this
> >issue fully resolved in Ubuntu (and guarantees that the same will get into
> >Debian) so I can use those paths to base CMake implementation on.
> can't see why it wouldn't be consistent. it's missing
> /lib/<multiarch>, but this directory shouldn't have any files needed
> for linking, only for dynamic linking. however, it looks like
> /usr/local/lib/<multiarch> is missing here.
I was using gcc -print-search-dirs, rather than gcc -v, but on a natty
system both methods expose the inconsistency:
$ gcc -v /dev/null |& sed -n -e's/^LIBRARY_PATH=//p' | sed -e's/:/\n/g' \
| xargs -n1 readlink -f | grep -v gcc
/usr/lib/x86_64-linux-gnu
/lib
/usr/lib
/usr/lib/x86_64-linux-gnu
$
$ gcc -print-search-dirs | sed -n -e's/^libraries: =//p' | sed -e's/:/\n/g' \
| xargs -n1 readlink -f | grep -vE 'gcc|/[0-9.]+$'
/usr/x86_64-linux-gnu/lib
/usr/lib/x86_64-linux-gnu
/lib
/usr/lib
/usr/lib/x86_64-linux-gnu
$
/usr/local/lib is missing entirely from the output, both with or without the
multiarch triplet; so that's orthogonal to the multiarch question. However,
while /lib is listed here, /lib/<triplet> is *not*. I haven't gotten to the
bottom of this yet to understand why this is so, but it is inconsistent. As
you say, /lib/<triplet> shouldn't be needed for linking, but neither should
/lib; either we're wrong about there not being a reason and we should have
both of them, or we should try to drop /lib as well for consistency.
> you should not rely on this information anyway, as ld may be used
> directly to link with.
The issue is that cmake walks the filesystem directly in order to do library
detection, and currently it has a hard-coded path for libraries. We don't
want that - we want it to inherit the search path from the compiler if
possible. Linking directly with ld should be a non-issue, as cmake
shouldn't be *invoking* ld when it does the linking, it should be invoking
the compiler. What we want there is for cmake and gcc to have a consistent
view of the search path without cmake having to query dpkg-architecture,
since that's a Debian-specific interface - if it can extract this
information from gcc output directly, that's an upstreamable patch that will
let cmake transparently pick up multiarch support whenever and wherever
other distributions add it.
Cheers,
--
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/
slanga...@ubuntu.com vor...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
