[cmake-developers] [CMake 0012037]: support multiarch lib paths for Debian/Ubuntu
Mantis Bug Tracker
mantis at public.kitware.com
Sun Apr 3 16:28:15 EDT 2011
The following issue has been SUBMITTED.
======================================================================
http://public.kitware.com/Bug/view.php?id=12037
======================================================================
Reported By: Modestas Vainius
Assigned To:
======================================================================
Project: CMake
Issue ID: 12037
Category: CMake
Reproducibility: N/A
Severity: major
Priority: high
Status: new
======================================================================
Date Submitted: 2011-04-03 16:28 EDT
Last Modified: 2011-04-03 16:28 EDT
======================================================================
Summary: support multiarch lib paths for Debian/Ubuntu
Description:
Debian 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
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
)
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2011-04-03 16:28 Modestas VainiusNew Issue
======================================================================
More information about the cmake-developers
mailing list