MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012037CMakeCMakepublic2011-04-03 16:282012-11-26 16:18
ReporterModestas Vainius 
Assigned ToBrad King 
PriorityhighSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
Platformamd64OSDebian GNU/LinuxOS Versionsid
Product VersionCMake 2.8.4 
Target VersionCMake 2.8.5Fixed in VersionCMake 2.8.5 
Summary0012037: support multiarch lib paths for Debian/Ubuntu
DescriptionDebian and Ubuntu are switching to the multiarch implementation which is unique in the current Linux world. You can find more about this effort here [1]. The switch affects layout of the /lib and /usr/lib directories [2]. The latter seems to cause cmake trouble finding system libraries [3]. There is a patch [4][ additional info] proposed to fix this issue but I don't think it is acceptable outside Debian/Ubuntu in its current form.

I see at least 3 problems with the patch:

1) dpkg-architecture is not guaranteed to be available on all Debian systems (it's in the dpkg-dev package which is not installed by default);

2) older dpkg-architecture versions do not even support `dpkg-architecture -qDEB_HOST_MULTIARCH`. This is only supported in dpkg 1.16 or later (released only 2 days ago).

3) the patch implements debian-specific feature like it affected all unix systems. There is no special casing.

What's more, I'm not sure if the patch covers all cases which might break. Therefore, I would like to discuss a proper implementation with you. Please note that vanilla cmake will slowly become unusable on the future Debian (wheezy+, 7.0) and Ubuntu (natty+, 11.04) systems unless this bug is fixed. I suppose this is definitely not what you want to happen... Btw, the issue is pretty high priority for me at the moment.

So here I propose a couple of proper (in my opinion) solutions in the order of my preference:

1) Parse `gcc -print-search-dirs` output and preseed CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES with information from the "libraries: =" line. This line contains some useless cruft and needs to be filtered a bit though. For example, this could be done with `gcc -print-search-dirs | sed -n -e's/libraries: =//p' | sed -e's/:/\n/g' | xargs -n1 readlink -f | grep -v 'gcc\|/[0-9.]\+$'` in shell scripting (needs to be rewritten for cmake). The multiarch triplet itself could be extracted from the well known path in the list, e.g. /usr/lib/${triplet}.

Why do I think this solution is the best?

* CMake does not need to second guess the arch-triplet (like in the other solution below).
* This would presumably be perfect for automatic cross compiling support.
* It should also work on all GNU linux distros despite their multiarch model but you may special case it for Debian/Ubuntu at the first phase.
* It is probably the right thing to do.

2) Link library search path will be like /usr/lib/${triplet}:/usr/lib:/lib/${triplet}:/lib (not sure 100% about the order if it's important). So here you need to second guess the triplet. Typically `dpkg-architecture -qDEB_HOST_MULTIARCH` would return it, but as noted earlier dpkg-architecture might not be available. At the moment, Debian multiarch triplet is a GNU tripplet returned by `gcc -dumpmachine` with the following adjustments done (code in perl):

sub gnutriplet_to_multiarch($)
{
    my ($gnu) = @_;
    my ($cpu, $cdr) = split('-', $gnu, 2);

    if ($cpu =~ /^i[456]86$/) {
    return "i386-$cdr";
    } else {
    return $gnu;
    }
}

Disadvantages of this solution is that these adjustments might change as new architectures are added. cmake implementation would need to be updated whenever this happens.

Feel free to ask questions. I will relay them to the person responsible for multiarch implementation in Debian/Ubuntu. Maybe he will even join us here.


[1] http://wiki.debian.org/Multiarch [^]
[2] https://wiki.ubuntu.com/MultiarchSpec [^] Design -> Filesystem layout section
[3] https://bugs.launchpad.net/debian/+source/cmake/+bug/737137 [^]
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618932#5 [^] see attachment
Steps To Reproduce
Additional Information--- 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
   )
 
TagsNo tags attached.
Relationships
related to 0011964closed Eric NOULARD Handle lib64 library on Linux 
has duplicate 0012254closed  Hardcoded CMAKE_SYSTEM_LIBRARY_PATH is no good. 
related to 0012049closed Philip Lowman Problem with cmake module FindGTK2.cmake in Ubuntu >= 11.04 (Natty Narwhal) 
related to 0012247closed Brad King python libraries are not searched under lib64/ 
related to 0012326closed Brad King [linux multiarch] /lib/<arch> is not in implicit link directories list 
related to 0012428closed Kitware Robot PathScale compiler support isn't multiarch aware 
related to 0013280closed  CMake does not detect multi-arch library architecture from hand-built gcc 4.7  
related to 0013742closed Brad King support multiarch include paths for Debian/Ubuntu 
Attached Filespatch v1-0f939ee1+0001-Teach-find_-library-package-about-Linux-multiarch-12.patch (15,725) 2011-06-08 10:29
https://public.kitware.com/Bug/file/3920/v1-0f939ee1%2B0001-Teach-find_-library-package-about-Linux-multiarch-12.patch
patch v1-0f939ee1+0002-Test-find_package-multiarch-support-12037.patch (5,415) 2011-06-08 10:30
https://public.kitware.com/Bug/file/3921/v1-0f939ee1%2B0002-Test-find_package-multiarch-support-12037.patch
diff regex-update-arm-eabi-kfreebsd-hurd.diff (1,881) 2011-06-12 10:40
https://public.kitware.com/Bug/file/3935/regex-update-arm-eabi-kfreebsd-hurd.diff
Issue History
Date ModifiedUsernameFieldChange
2011-04-03 16:28Modestas VainiusNew Issue
2011-04-04 02:23Eric NOULARDNote Added: 0026028
2011-04-04 02:23Eric NOULARDRelationship addedrelated to 0011964
2011-04-04 03:00Eric NOULARDNote Added: 0026029
2011-04-04 03:01Eric NOULARDNote Edited: 0026029bug_revision_view_page.php?bugnote_id=26029#r283
2011-04-04 03:03Eric NOULARDNote Edited: 0026029bug_revision_view_page.php?bugnote_id=26029#r284
2011-04-04 05:31Modestas VainiusNote Added: 0026032
2011-04-04 06:38Eric NOULARDNote Added: 0026033
2011-04-06 07:42Eric NOULARDRelationship addedrelated to 0012049
2011-04-06 11:55Brad KingNote Added: 0026124
2011-04-06 15:43Modestas VainiusNote Added: 0026126
2011-05-19 16:11Alex NeundorfNote Added: 0026557
2011-06-07 08:19Eric NOULARDRelationship addedrelated to 0012247
2011-06-07 08:21Eric NOULARDRelationship addedrelated to 0012248
2011-06-07 16:15Brad KingRelationship addedrelated to 0012254
2011-06-07 16:28Modestas VainiusNote Added: 0026743
2011-06-07 16:52Brad KingNote Added: 0026744
2011-06-07 16:57Brad KingNote Added: 0026745
2011-06-07 17:40Modestas VainiusNote Added: 0026746
2011-06-07 18:20Modestas VainiusNote Added: 0026747
2011-06-08 08:18Brad KingRelationship replacedhas duplicate 0012254
2011-06-08 08:56Mikael ÖhmanNote Added: 0026756
2011-06-08 10:11Brad KingAssigned To => Brad King
2011-06-08 10:11Brad KingStatusnew => assigned
2011-06-08 10:29Brad KingFile Added: v1-0f939ee1+0001-Teach-find_-library-package-about-Linux-multiarch-12.patch
2011-06-08 10:30Brad KingFile Added: v1-0f939ee1+0002-Test-find_package-multiarch-support-12037.patch
2011-06-08 10:30Brad KingNote Added: 0026761
2011-06-08 10:35Brad KingNote Added: 0026762
2011-06-08 11:44Mikael ÖhmanNote Edited: 0026756bug_revision_view_page.php?bugnote_id=26756#r346
2011-06-09 03:58Modestas VainiusNote Added: 0026801
2011-06-09 13:49Brad KingNote Added: 0026809
2011-06-11 06:55Modestas VainiusNote Added: 0026834
2011-06-12 10:40Modestas VainiusFile Added: regex-update-arm-eabi-kfreebsd-hurd.diff
2011-06-12 10:42Modestas VainiusNote Added: 0026843
2011-06-13 11:33Brad KingNote Added: 0026849
2011-06-13 11:39Brad KingNote Added: 0026850
2011-06-14 13:26Brad KingNote Added: 0026855
2011-06-14 13:26Brad KingStatusassigned => resolved
2011-06-14 13:26Brad KingFixed in Version => CMake 2.8.5
2011-06-14 13:26Brad KingResolutionopen => fixed
2011-06-14 13:33Brad KingRelationship deletedrelated to 0012248
2011-06-18 07:40David ColeTarget Version => CMake 2.8.5
2011-07-20 16:18Alex NeundorfNote Added: 0027058
2011-07-20 16:18Alex NeundorfStatusresolved => feedback
2011-07-20 16:18Alex NeundorfResolutionfixed => reopened
2011-07-21 02:25Modestas VainiusNote Added: 0027059
2011-07-21 02:25Modestas VainiusStatusfeedback => assigned
2011-07-25 13:20Brad KingNote Added: 0027064
2011-07-25 13:20Brad KingStatusassigned => closed
2011-07-25 13:20Brad KingResolutionreopened => fixed
2011-07-25 13:21Brad KingRelationship addedrelated to 0012326
2011-08-29 15:26Brad KingRelationship addedrelated to 0012428
2012-06-18 08:14Brad KingRelationship addedrelated to 0013280
2012-11-26 16:18Brad KingRelationship addedrelated to 0013742

Notes
(0026028)
Eric NOULARD   
2011-04-04 02:23   
Hi Modestas,

We did have related discussion concerning lib64 handling for CPack (RPM)
http://www.cmake.org/Bug/view.php?id=11964. [^]

I think that if we were to patch the Platform/*.cmake file one
should preferably do it in Platform/Linux.cmake
and not in Platform/UnixPath.cmake, unless this has to be shared
with other unices?
 
You'll already find a small debian specific part in Linux.cmake.

Now as you'll soon discover in the related bug, may be
the discussion concerning could be done with CPack usage in mind too.
That would help people with building appropriate package for linux,
i.e. package using the "normalized" lib path.
(0026029)
Eric NOULARD   
2011-04-04 03:00   
(edited on: 2011-04-04 03:03)
Some more comments.
The fact that 2) older dpkg-architecture versions do not even support `dpkg-architecture -qDEB_HOST_MULTIARCH`, is not a problem
because (correct me if I'm wrong) but as soons as some Debian-based distro is released then I bet the dpkg-architecture coming along with it should be up-to-date, right? So if dpkg-architecture bails out on DEB_HOST_MULTIARCH then we can go back to current behavior.

Now about 1) dpkg-architecture is not guaranteed to be available on all Debian systems, then I see two point of view:
    PV1) Requiring -dev packages for a CMake user is not a problem,
         because compiling is kind of "development activity".
         In this CMake may warn that a SystemSpecific required
         tool is missing and its (the one of CMake) behavior without it
         will be at best sub-optimal if not wrong.

    PV2) Debian people should make the tool mandatory in the distro
         or have some fallback (/etc/some_file) which makes it possible
         to properly get the MULTIARCH_TRIPLET.

In the end I think that if some Linux distribution has a specific behavior
it is somehow logical to use distro-specific tools to handle it. That's why
I would advice Debian developers to go for PV2 because you cannot expect
"external" tools to adapt themselves without minimal help.
(0026032)
Modestas Vainius   
2011-04-04 05:31   
I don't think /etc/some_file is appropriate. /etc and /usr/share will be shared between binaries from different arches or one may migrate /etc/ to another host so it will get out-of-date very soon. One of the features of Debian multiarch is that linker and compiler solve all multiarch issues so they are the primary source of information.

Regarding your notes about dpkg-architecture, if that's what you want to do (requiring user to install dpkg-dev package), you can go that way. It's not a problem for me to add this dependency to the cmake package. My points were about current state of the patch which you may choose to solve or ignore.

I still like `gcc -print-search-dirs` solution the most as it's more universal. Before you adopt one solution or another, have in mind cross-compiling as well. If you adopted `gcc -print-search-dirs`, setting proper CMAKE_C_COMPILER should be enough.
(0026033)
Eric NOULARD   
2011-04-04 06:38   
Just to be clear, I'm not a decision maker here :-]
I'm just putting forward some idea.
Kitware people are the decision makers.

Now, the use of gcc seams reasonable as well
and you make a good point about covering the cross-compiling case.
Moreover I mentioned "requiring -dev package" as an option but I bet
this wouldn't be the best one.
CMake try hard not to depend on external libs, even less on

My main point is finding libraries may not be "enough" because
CMake is used to build **AND** install things so how should the MultiArch
switch be handled?

How do we help the user to
INSTALL(... DESTINATION /lib/${APPROPRIATE_DIR}...)
may the GNUInstallDirs.cmake module be updated for the multi-arch case?
(0026124)
Brad King   
2011-04-06 11:55   
Take a look in CMakeFiles/CMake*Compiler.cmake in any build tree. There you will see the implicit link directories detected from the toolchains. Perhaps we need to teach find_library to start looking in these.

The lib->lib64 transformation already used on non-Debian 64-bit systems is similar to this. Perhaps that code can be generalized.

Will these triplets appear under lib directories other than the standard /lib and /usr/lib (and perhaps /usr/local/lib) by any convention defined by the multiarch standard?
(0026126)
Modestas Vainius   
2011-04-06 15:43   
For now the standard covers /lib, /usr/lib, /usr/local/lib. Bigger software like firefox will be installed into /usr/lib/triplet/firefox etc. As you can see from bug 12049, glib stuff gets installed into /usr/lib/tripplet/glib-2.0/. Likewise, find_package() Config.cmake files should go to /usr/lib/triplet/cmake. In other words, whatever is under /usr/lib currently will go to /usr/lib/current-arch-triplet to make room for other arch to be installed under /usr/lib/other-arch-triplet. /lib, /usr/lib etc. are kept for backwards/FHS compatibility and gradual switch.

/usr/bin etc. are not affected by multiarch because typically it does not matter for which arch the executables were compiled for.
(0026557)
Alex Neundorf   
2011-05-19 16:11   
The file Modules/CMakeFindEclipseCDT4.cmake already parses some output from gcc, to find the builtin include dirs and macros.
Maybe this part of cmake code can be reused somewhere for the multiarch lib stuff.
(0026743)
Modestas Vainius   
2011-06-07 16:28   
Ok, multiarch has come to Debian unstable. Basically after 2 months of silence in this bug, it looks like I will have to go with a hack. I tried looking into developing a better solution myself but didn't get far. Anyway, it's only the start of my headaches... many Find* module hardcode /usr/lib paths...
(0026744)
Brad King   
2011-06-07 16:52   
The main problem is determining the architecture triplet reliably. We must be able to determine it given only the compiler toolchain and flags (e.g. -m64). Tools specific to the host system might not accurately reflect the target architecture, especially when cross-compiling.

Don't worry about the Find* modules that hardcode /usr/lib. Those hard-coded paths are not searched until after the rest of paths from variables like CMAKE_SYSTEM_PREFIX_PATH are searched.
(0026745)
Brad King   
2011-06-07 16:57   
As I mentioned in 0012037:0026124 CMake does detect implicit link directories from the toolchain. Will these always include the /usr/lib/triplet directory? Run CMake on some project using the toolchain for a given triplet and look at CMakeFiles/CMake*Compiler.cmake to see what directories it detects.
(0026746)
Modestas Vainius   
2011-06-07 17:40   
Architecture is amd64.

Used to be (pre-multiarch):

$ grep LINK_DIRECTORIES CMakeFiles/CMake*Compiler.cmake
CMakeFiles/CMakeCCompiler.cmake:SET(CMAKE_C_IMPLICIT_LINK_DIRECTORIES "/usr/lib/gcc/x86_64-linux-gnu/4.6.1;/usr/lib;/lib")
CMakeFiles/CMakeCXXCompiler.cmake:SET(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "/usr/lib/gcc/x86_64-linux-gnu/4.6.1;/usr/lib;/lib")

It is now (multiarch enabled):

$ grep LINK_DIRECTORIES CMakeFiles/CMake*Compiler.cmake
CMakeFiles/CMakeCCompiler.cmake:SET(CMAKE_C_IMPLICIT_LINK_DIRECTORIES "/usr/lib/gcc/x86_64-linux-gnu/4.6.1;/usr/lib;/lib;/usr/lib/x86_64-linux-gnu")
CMakeFiles/CMakeCXXCompiler.cmake:SET(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "/usr/lib/gcc/x86_64-linux-gnu/4.6.1;/usr/lib;/lib;/usr/lib/x86_64-linux-gnu")

$ gcc -v -xc -E /dev/null
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.0-11' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs [^] --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 20110604 (prerelease) (Debian 4.6.0-11)
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.6.1/cc1 -E -quiet -v /dev/null -mtune=generic -march=x86-64
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include-fixed
 /usr/include
End of search list.
# 1 "/dev/null"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/dev/null"
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../:/lib/:/usr/lib/:/usr/lib/x86_64-linux-gnu/
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=x86-64'

Multiarch paths are also in /etc/ld.so.conf:

$ cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf

$ cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

For example, on i386 there is /etc/ld.so.conf.d/i486-linux-gnu.conf
But please note that both (or more) such confs can be installed at the same time (the whole point of multiarch).
(0026747)
Modestas Vainius   
2011-06-07 18:20   
However, on the up-to-date Ubuntu oneiric CMAKE_{C,CXX}_IMPLICIT_LINK_DIRECTORIES are a bit different (no /usr/lib;/lib).

# grep LINK_DIRECTORIES CMakeFiles/CMake*Compiler.cmake
CMakeFiles/CMakeCCompiler.cmake:SET(CMAKE_C_IMPLICIT_LINK_DIRECTORIES "/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1;/usr/lib/x86_64-linux-gnu")
CMakeFiles/CMakeCXXCompiler.cmake:SET(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1;/usr/lib/x86_64-linux-gnu")

I don't know why it is different, but in either case, you can rely on /usr/lib/triplet to be there.

Also please note that /lib/triplet is not in CMAKE_{C,CXX}_IMPLICIT_LINK_DIRECTORIES lists on both Debian and Ubuntu. That's probably because library development symlinks (libNAME.so) are never installed to /lib. But maybe this could be treated as bug [1] ...

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618932#34 [^]
(0026756)
Mikael Öhman   
2011-06-08 08:56   
(edited on: 2011-06-08 11:44)
How should *LibraryDepends.cmake files treat this?
These autogenerated files hardcode whatever paths they were compiled with. But with custom libraries, and/or ld.so.conf, these paths might change dynamically.

As you know, this is also what has happened in Sid right now (e.g. /usr/lib/x86_64-linux-gnu/libld.so), rendering all *Config.cmake files supplied (VTK, Paraview, etc.) broken (they all hardcode /usr/lib/libdl.so). While this can be argued to be treated as a package bug, I think it would be more flexible and easier to maintain if actually used find_library or such.

Will the compiler/linker selectively include only the corresponding config file from /etc/ld.so.conf.d/ in multiarch? Are they hardcoded? In that case, is ld.so.conf deprecated?
The wikis doesn't mention ld.so.conf at all, even though it should be absolutely vital.

Edit: I apologize for the confused, incorrect statements above. I was confused about the linker behavior. The /etc/ld.so.conf file is not used by the linker and shouldn't be used by CMake either.
(0026761)
Brad King   
2011-06-08 10:30   
Re 0012037:0026747: Please try the v1-0f939ee1+000[12]* patch series.
(0026762)
Brad King   
2011-06-08 10:35   
Re 0012037:0026756: The export_library_depends command has been superseded by install(EXPORT) and export():

  http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages [^]
  http://www.cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets [^]

I believe the new approach is in use in VTK 5.8 (or perhaps 5.10).
(0026801)
Modestas Vainius   
2011-06-09 03:58   
Thank you, Brad. Both patches work (tested on top of 2.8.4). I tested find_library() in the real world. I checked find_package() with strace and it seems like it should work too.

1) These patches also lay down a path for fixing Find* modules. I fixed FindGTK2.cmake like this:

--- a/Modules/FindGTK2.cmake
+++ b/Modules/FindGTK2.cmake
@@ -187,6 +187,7 @@ function(_GTK2_FIND_INCLUDE_DIR _var _hd
         PATHS
             /usr/local/lib64
             /usr/local/lib
+ /usr/lib/${CMAKE_LIBRARY_ARCHITECTURE}
             /usr/lib64
             /usr/lib
             /opt/gnome/include

However, if ${CMAKE_LIBRARY_ARCHITECTURE} is not set, /usr/lib will be checked twice in a bit wrong order. Could something be improved here (without IFs or moving down /usr/lib/${CMAKE_LIBRARY_ARCHITECTURE} above /usr/lib64)?

2) Will those patches be part of 2.8.5? I want to emphasize that released Ubuntu 11.04 (natty) already has this multiarch enabled so upstream cmake up to and including 2.8.4 is basically unusable on those systems. That's because libc6 package is multiarch enabled and e.g. vanilla cmake 2.8.4 is not even able to set CMAKE_DL_LIBS properly.
(0026809)
Brad King   
2011-06-09 13:49   
Re 0012037:0026801: Thanks for testing the patches. I merged them to the CMake 'next' branch:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b41ad3b3 [^]
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=52a6ed2a [^]

I still need to consult with some other developers to see if this design is acceptable as a permanent solution.

For GTK2 they actually install headers into <prefix>/lib? Are all the headers architecture-specific? How are projects built with other build systems supposed to find the headers? Does it always come with pkgconfig or some kind of gtk2-config script?
(0026834)
Modestas Vainius   
2011-06-11 06:55   
> For GTK2 they actually install headers into <prefix>/lib? Are all the headers
> architecture-specific?

https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/751940/comments/6 [^]

> How are projects built with other build systems supposed to find the headers?
> Does it always come with pkgconfig or some kind of gtk2-config script?

https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/751940/comments/1 [^]

The latter is probably the subject of another bug.
(0026843)
Modestas Vainius   
2011-06-12 10:42   
I have just uploaded regex-update-arm-eabi-kfreebsd-hurd.diff. It contains fixes for v1-0f939ee1+0001-Teach-find_-library-package-about-Linux-multiarch-12.patch:

From: Modestas Vainius <modax@debian.org>
Subject: CMAKE_LIBRARY_ARCHITECTURE_REGEX fixes and improvements
Date: Sun, 12 Jun 2011 17:40:01 +0300

* Fix linux CMAKE_LIBRARY_ARCHITECTURE_REGEX to support armel-linux-gnueabi.
* Add CMAKE_LIBRARY_ARCHITECTURE_REGEX on kFreeBSD.
* Add CMAKE_LIBRARY_ARCHITECTURE_REGEX on GNU (Hurd).

Also regex is improved to support quadlets. Even if I have not seen this in the
wild yet, reportedly they are possible.

The patch should be applied on top of
v1-0f939ee1+0001-Teach-find_-library-package-about-Linux-multiarch-12.patch
(0026849)
Brad King   
2011-06-13 11:33   
Re 0012037:0026834: Thanks. See my entry in the related issue: 0012049:0026848
(0026850)
Brad King   
2011-06-13 11:39   
Re 0012037:0026843: Thanks for the patch. Those expressions look good. Applied:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1ed19bcb [^]
(0026855)
Brad King   
2011-06-14 13:26   
I merged the commits mentioned in 0012037:0026809 and 0012037:0026850 to our 'master' branch in preparation for inclusion in the 2.8.5 release.
(0027058)
Alex Neundorf   
2011-07-20 16:18   
There is another entry in the tracker, which seems to be related, 0011260.
Is this also fixed with your changes ?

Alex
(0027059)
Modestas Vainius   
2011-07-21 02:25   
Multiarch does not have much to do with amd64 biarch (paths are different as multiarch does not use /usr/lib32 or /usr/lib64). Let's not mix there two into one.
(0027064)
Brad King   
2011-07-25 13:20   
Agreed. Closing again.