Bug#618932: cmake multiarch support

[Steve Langasek]

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/, but this directory shouldn't have any files needed
> for linking, only for dynamic linking. however, it looks like
> /usr/local/lib/ 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/ 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/ 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 Developerhttp://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

Bug#618932: cmake multiarch support

[Matthias Klose]

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/, but this 
directory shouldn't have any files needed for linking, only for dynamic linking. 
however, it looks like /usr/local/lib/ 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

Bug#618932: cmake multiarch support

[Modestas Vainius]

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.

I'm willing to be flexible enough and trust me, cmake won't end up being a 
multiarch blocker. But I will take as much time as possible to implement a 
proper fix but at this point I need some help from toolchain. I do NOT 
consider current patches to be acceptable and they might only work as a last 
minute fixes when there is no other choice.

P.S. NMU without explicit permission would be considered as offensive action 
unless I start not reacting to mails for some reason.

-- 
Modestas Vainius 


signature.asc
Description: This is a digitally signed message part.

Bug#618932: cmake multiarch support

[Steve M. Robbins]

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.

Thanks for considering this request,
-Steve


signature.asc
Description: Digital signature

Bug#618932: cmake multiarch support

[Simon McVittie]

> > This patch adds support for multiarch library directories to cmake.  It
> > also needs a runtime dependency on dpkg-dev.

For the record, this appears to be the same thing as
.

S



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#618932: cmake multiarch support

[Modestas Vainius]

severity 618932 important
thanks

Hello,

On šeštadienis 19 Kovas 2011 19:37:53 Jonathan Riddell wrote:
> Package: cmake
> 
> Unlike autoconf, cmake doesn't use the linker to find libraries.

Well, then probably it should. Do you know the details how autoconf does it?

> 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 don't think cmake upstream can 
afford to ignore Debian or Ubuntu so they will eventually have to implement 
something to support our configuration. So it would be better if we worked 
with them from the start, then nobody would need to reinvent the wheel and 
everybody would be happy.

However, I don't have much clue about multiarch at the moment. Technical 
details are sparse and required dpkg-dev is not even available in unstable. 
Neither debhelper is able to handle it yet. Therefore, I prefer to wait until 
dust settles down a bit and get things right.

-- 
Modestas Vainius 


signature.asc
Description: This is a digitally signed message part.

Bug#618932: cmake multiarch support

[Jonathan Riddell]

Package: cmake

Unlike autoconf, cmake doesn't use the linker to find libraries.

This patch adds support for multiarch library directories to cmake.  It also 
needs a runtime dependency on dpkg-dev.

Jonathan
--- cmake-2.8.3.orig/Source/cmFindBase.cxx
+++ cmake-2.8.3/Source/cmFindBase.cxx
@@ -324,6 +324,14 @@ void cmFindBase::AddPrefixPaths(std::vec
   {
   dir += "/";
   }
+if (subdir == "lib")
+  {
+  const char* triplet = 
this->Makefile->GetDefinition("CMAKE_ARCH_TRIPLET");
+  if (triplet)
+{
+this->AddPathInternal(dir+"lib/"+triplet, pathType);
+}
+  }
 std::string add = dir + subdir;
 if(add != "/")
   {
--- cmake-2.8.3.orig/Modules/Platform/UnixPaths.cmake
+++ cmake-2.8.3/Modules/Platform/UnixPaths.cmake
@@ -29,6 +29,8 @@ SET(UNIX 1)
 GET_FILENAME_COMPONENT(_CMAKE_INSTALL_DIR "${CMAKE_ROOT}" PATH)
 GET_FILENAME_COMPONENT(_CMAKE_INSTALL_DIR "${_CMAKE_INSTALL_DIR}" PATH)
 
+EXECUTE_PROCESS(COMMAND dpkg-architecture -qDEB_HOST_MULTIARCH OUTPUT_VARIABLE 
CMAKE_ARCH_TRIPLET OUTPUT_STRIP_TRAILING_WHITESPACE)
+
 # List common installation prefixes.  These will be used for all
 # search types.
 LIST(APPEND CMAKE_SYSTEM_PREFIX_PATH
@@ -74,6 +76,7 @@ LIST(APPEND CMAKE_SYSTEM_PROGRAM_PATH
   )
 
 LIST(APPEND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES
+  /lib/${CMAKE_ARCH_TRIPLET} /usr/lib/${CMAKE_ARCH_TRIPLET}
   /lib /usr/lib /usr/lib32 /usr/lib64
   )