MantisBT - CMake |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0014875 | CMake | Modules | public | 2014-04-14 13:15 | 2014-10-06 10:33 |
|
Reporter | Peter Wu | |
Assigned To | Brad King | |
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | |
Platform | x86_64 | OS | Arch Linux | OS Version | |
Product Version | CMake 2.8.12.2 | |
Target Version | CMake 3.0 | Fixed in Version | CMake 3.0 | |
|
Summary | 0014875: /lib64 wrongfully appears in RPATH |
Description | When 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 Reproduce | Create 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 Information | This 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. |
Tags | No tags attached. |
Relationships | related to | 0014884 | closed | Kitware Robot | Arch Linux may need FIND_LIBRARY_USE_LIB64_PATHS |
|
Attached Files | UnixPaths.patch (337) 2014-04-14 13:15 https://public.kitware.com/Bug/file/5128/UnixPaths.patch |
|
Issue History |
Date Modified | Username | Field | Change |
2014-04-14 13:15 | Peter Wu | New Issue | |
2014-04-14 13:15 | Peter Wu | File Added: UnixPaths.patch | |
2014-04-14 13:19 | Ben Boeckel | Note Added: 0035693 | |
2014-04-14 13:21 | Peter Wu | Note Added: 0035694 | |
2014-04-14 15:01 | Brad King | Note Added: 0035696 | |
2014-04-14 15:07 | Peter Wu | Note Added: 0035697 | |
2014-04-14 15:19 | Brad King | Note Added: 0035698 | |
2014-04-14 15:41 | Peter Wu | Note Added: 0035699 | |
2014-04-14 16:10 | Brad King | Note Added: 0035700 | |
2014-04-14 16:24 | Peter Wu | Note Added: 0035701 | |
2014-04-16 11:48 | Brad King | Note Added: 0035727 | |
2014-04-16 11:53 | Peter Wu | Note Added: 0035728 | |
2014-04-16 14:20 | Brad King | Note Added: 0035731 | |
2014-04-16 15:59 | Peter Wu | Note Added: 0035732 | |
2014-04-17 10:04 | Brad King | Relationship added | related to 0014884 |
2014-04-17 10:07 | Brad King | Note Added: 0035734 | |
2014-04-17 10:07 | Brad King | Assigned To | => Brad King |
2014-04-17 10:07 | Brad King | Status | new => resolved |
2014-04-17 10:07 | Brad King | Resolution | open => fixed |
2014-04-17 10:07 | Brad King | Fixed in Version | => CMake 3.0 |
2014-04-17 10:07 | Brad King | Target Version | => CMake 3.0 |
2014-10-06 10:33 | Robert Maynard | Note Added: 0036979 | |
2014-10-06 10:33 | Robert Maynard | Status | resolved => 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
|
|
|
|
(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. |
|