MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0014875CMakeModulespublic2014-04-14 13:152014-10-06 10:33
ReporterPeter Wu 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
Platformx86_64OSArch LinuxOS Version
Product VersionCMake 2.8.12.2 
Target VersionCMake 3.0Fixed in VersionCMake 3.0 
Summary0014875: /lib64 wrongfully appears in RPATH
DescriptionWhen a program is built, the /lib64 directory appears in RPATH which breaks local testing of a build if a library used by the program appears in /lib64.

Originally reported at https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9989. [^]
Steps To ReproduceCreate the following CMakeLists.txt file, ensure that /lib64 exists:

cmake_minimum_required (VERSION 2.6)
project ("bug test")
# test.c: int main(void){return 0;}
add_executable(test test.c)
target_link_libraries(test /lib64/libglib-2.0.so.0)

After compilation, `chrpath test` should show nothing. Instead, it shows RPATH=lib64
Additional InformationThis is Arch Linux package cmake 2.8.12.2-2
/lib64 and /lib are symlinked to usr/lib
/usr/lib64 is symlinked to lib

The attached patch fixes the issue.
TagsNo tags attached.
Relationships
related to 0014884closed Kitware Robot Arch Linux may need FIND_LIBRARY_USE_LIB64_PATHS 
Attached Filespatch UnixPaths.patch (337) 2014-04-14 13:15
https://public.kitware.com/Bug/file/5128/UnixPaths.patch
Issue History
Date ModifiedUsernameFieldChange
2014-04-14 13:15Peter WuNew Issue
2014-04-14 13:15Peter WuFile Added: UnixPaths.patch
2014-04-14 13:19Ben BoeckelNote Added: 0035693
2014-04-14 13:21Peter WuNote Added: 0035694
2014-04-14 15:01Brad KingNote Added: 0035696
2014-04-14 15:07Peter WuNote Added: 0035697
2014-04-14 15:19Brad KingNote Added: 0035698
2014-04-14 15:41Peter WuNote Added: 0035699
2014-04-14 16:10Brad KingNote Added: 0035700
2014-04-14 16:24Peter WuNote Added: 0035701
2014-04-16 11:48Brad KingNote Added: 0035727
2014-04-16 11:53Peter WuNote Added: 0035728
2014-04-16 14:20Brad KingNote Added: 0035731
2014-04-16 15:59Peter WuNote Added: 0035732
2014-04-17 10:04Brad KingRelationship addedrelated to 0014884
2014-04-17 10:07Brad KingNote Added: 0035734
2014-04-17 10:07Brad KingAssigned To => Brad King
2014-04-17 10:07Brad KingStatusnew => resolved
2014-04-17 10:07Brad KingResolutionopen => fixed
2014-04-17 10:07Brad KingFixed in Version => CMake 3.0
2014-04-17 10:07Brad KingTarget Version => CMake 3.0
2014-10-06 10:33Robert MaynardNote Added: 0036979
2014-10-06 10:33Robert MaynardStatusresolved => closed

Notes
(0035693)
Ben Boeckel   
2014-04-14 13:19   
Ah, the joys of UsrMove. Is the full path actually showing up in target_link_libraries (presumably as a variable expansion)?
(0035694)
Peter Wu   
2014-04-14 13:21   
Yes, I see the whole /lib64/libglib-2.0.so path. I found it when adding --debug --trace to the cmake command.
(0035696)
Brad King   
2014-04-14 15:01   
The list of implicit link directories to be excluded from the RPATH is computed here:

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmComputeLinkInformation.cxx;hb=v3.0.0-rc3#l1664 [^]

It considers the CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES value that is supposed to be computed from the actual compiler implicit directories. Normally it should include directories like /lib64 if the compiler toolchain uses them. That variable is stored under the build tree at CMakeFiles/<cmake-version>/CMake(C|CXX)Compiler.cmake. Is it there? What is its value?
(0035697)
Peter Wu   
2014-04-14 15:07   
Both the C and CXX cmake files contain:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2;/usr/lib;/lib

It has not been an issue before because /lib64 symlinks to /usr/lib which works for all programs except the one that depend on this mapping. Adding /lib64 seems sane to me, yet another more involving option is to resolve all symlinks and match them against the implicit paths.
(0035698)
Brad King   
2014-04-14 15:19   
Re 0014875:0035697: Adding lib64 paths to CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES is a reasonable proposal, but I want to see if there are other changes that need to be made too.

If Arch Linux has lib64 symlinks only for compatibility and prefers plain "/lib" paths then perhaps it should be treated like Debian:

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Linux.cmake;hb=v3.0.0-rc3#l53 [^]

For Debian we set the FIND_LIBRARY_USE_LIB64_PATHS global property to FALSE so that the find_* commands do not search lib64 paths by default.
(0035699)
Peter Wu   
2014-04-14 15:41   
Setting FIND_LIBRARY_USE_LIB64_PATHS to FALSE for Arch Linux seems a good idea as /lib64 and /usr/lib64 all point to /usr/lib.

Arch Linux is a rolling release distribution, but this change shouldn't be problematic as they moved to /usr/lib in July 2012:
https://www.archlinux.org/news/the-lib-directory-becomes-a-symlink/ [^]
(0035700)
Brad King   
2014-04-14 16:10   
Re 0014875:0035699: What is the proper way to detect that the current host is Arch Linux? We need a test equivalent to that linked in 0014875:0035698 for /etc/debian_version.

The Arch distribution of CMake could backport a patch to Modules/Platform/Linux.cmake to set FIND_LIBRARY_USE_LIB64_PATHS to FALSE even for 2.8.12.
(0035701)
Peter Wu   
2014-04-14 16:24   
The base filesystem package includes /etc/os-release containing:

NAME="Arch Linux"
ID=arch
PRETTY_NAME="Arch Linux"
ANSI_COLOR="0;36"
HOME_URL="https://www.archlinux.org/" [^]
SUPPORT_URL="https://bbs.archlinux.org/" [^]
BUG_REPORT_URL="https://bugs.archlinux.org/" [^]

You could also opt for feature detection and assume FIND_LIBRARY_USE_LIB64 FALSE if /lib64 is a symlink to /usr/lib (and /lib?) *and* /usr/lib64 points to /usr/lib.
(0035727)
Brad King   
2014-04-16 11:48   
Independent of FIND_LIBRARY_USE_LIB64 FALSE or symlinks in implicit paths, a change like that you first proposed is worthwhile anyway. Applied here:

 Drop /lib32 and /lib64 from link directories and RPATH
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cc57ff5c [^]

The Arch distribution should backport that for its CMake to avoid /lib64 in the RPATH now.
(0035728)
Peter Wu   
2014-04-16 11:53   
Do you foresee a cmake release in the near future containing this change? If not, then I'll request a backport, otherwise it will appear in Arch via a new cmake release.
(0035731)
Brad King   
2014-04-16 14:20   
Re 0014875:0035728: I based the fix in 0014875:0035727 on CMake 3.0.0-rc3 so it can be included in 3.0.0-rc4. However, it may still be a few weeks before the final 3.0 is tagged.
(0035732)
Peter Wu   
2014-04-16 15:59   
Ok, given that this bug is easy to workaround (edit the cmake file) and only occurs in specific cases (not-installed builds with RPATH), I think I am not going to bother the arch devs and instead wait for cmake 3.0.0.

Thanks for your time!
(0035734)
Brad King   
2014-04-17 10:07   
I filed 0014884 to propose FIND_LIBRARY_USE_LIB64_PATHS separately from this issue.

The fix in 0014875:0035727 has been merged to the 'release' branch in preparation for 3.0.0-rc4.
(0036979)
Robert Maynard   
2014-10-06 10:33   
Closing resolved issues that have not been updated in more than 4 months.