On 05/31/2011 09:23 PM, Modestas Vainius wrote:
Hello,
On sekmadienis 29 Gegužė 2011 05:51:58 Steve M. Robbins wrote:
On Sat, Mar 19, 2011 at 08:29:30PM +0200, Modestas Vainius wrote:
On ??e??tadienis 19 Kovas 2011 19:37:53 Jonathan Riddell wrote:
This patch adds support for multiarch library directories to cmake. It
also needs a runtime dependency on dpkg-dev.
That's the problem I have with this patch - it depends on dpkg-dev. I
believe this might make it unacceptable for upstream.
I'd agree that this kind of patch will be unsuitable for upstream. I
found that you've already proposed some alternatives in
http://www.cmake.org/Bug/view.php?id=12037
I'm just wondering, given Luk Claes' recent message
http://lists.debian.org/debian-devel/2011/05/msg01108.html
whether the patch to this bug or to your upstream CMake bug could
be implemented, at least as an interim measure, as this is one of
the blockers to bootstrapping multiarch.
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.
you should not rely on this information anyway, as ld may be used directly to
link with.
Matthias
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
