MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013419CMakeCMakepublic2012-07-18 10:512013-03-04 08:38
ReporterAndy Piper 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Platformx86_64OSOpenSuSE LinuxOS Versionall
Product VersionCMake 2.8.8 
Target VersionCMake 2.8.10Fixed in VersionCMake 2.8.10 
Summary0013419: Path mangled when searchign for lib64 directories
DescriptionWhen searching for "lib64" directories, all elements in the search-path that end with "lib" are changed to "lib64". This makes it impossible for CMake to find the libraries.


Steps To Reproduce1. Start up a OpenSUSE or SLES machine

2. Create a directory /var/lib/myproject/lib64

2a (optional, if you don't want to be root):
    # chown -R <youruser>:users /var/lib/myproject
    ...then do the remaining steps as <youruser>

3. Copy /usr/lib64/libz.so to /var/lib/myproject/lib64/

4. Create the file /var/lib/myproject/CMakeLists.txt with this content:

    cmake_minimum_required(VERSION 2.8)
    project(lib64bug)
    set(CMAKE_FIND_ROOT_PATH ${CMAKE_SOURCE_DIR})
    find_library(MYZLIB NAMES libz.so
        ONLY_CMAKE_FIND_ROOT_PATH)
    if(MYZLIB STREQUAL "MYZLIB-NOTFOUND")
        message(FATAL_ERROR "Did not find zlib under ${CMAKE_SOURCE_DIR}")
    endif()
    message(STATUS "Found zlib: ${MYZLIB}")

5. Create the directory /var/lib/myproject/build and cd into it

6. Run "cmake .."

- The expected CMake output should end with

"-- Found zlib: /var/myproject/lib64/libz.so"

- The actual CMake output is :

"CMake Error at CMakeLists.txt:7 (message):
  Did not find zlib under /var/lib/myproject


-- Configuring incomplete, errors occurred!"

7. To see the bug in action, run this command (under bash or sh):

    strace cmake .. 2>&1 | grep myproject/lib64

...the output will show the path /var/lib/myproject being mangled to /var/lib64/myproject
Additional Information/var/lib/jenkins/workspace is the default workspace-root for Jenkins CI installations on OpenSUSE (and possibly other Linux distributions). This exposes all jenkins projects to this bug.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-07-18 10:51Andy PiperNew Issue
2012-07-18 11:01Brad KingNote Added: 0030073
2012-07-18 11:03Brad KingNote Added: 0030074
2012-07-18 11:06Brad KingNote Added: 0030076
2012-07-18 11:08Brad KingNote Added: 0030077
2012-07-18 11:08Brad KingStatusnew => backlog
2012-07-18 12:15Andy PiperNote Added: 0030078
2012-07-18 13:50Rolf Eike BeerNote Added: 0030079
2012-07-18 14:46Brad KingNote Added: 0030081
2012-07-20 14:06Brad KingAssigned To => Brad King
2012-07-20 14:06Brad KingStatusbacklog => assigned
2012-07-20 14:24Brad KingNote Added: 0030098
2012-07-20 14:24Brad KingStatusassigned => resolved
2012-07-20 14:24Brad KingResolutionopen => fixed
2012-10-24 17:25David ColeFixed in Version => CMake 2.8.10
2012-10-24 17:25David ColeTarget Version => CMake 2.8.10
2013-03-04 08:38Robert MaynardNote Added: 0032481
2013-03-04 08:38Robert MaynardStatusresolved => closed

Notes
(0030073)
Brad King   
2012-07-18 11:01   
The lib->lib64 behavior is a feature:

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindLibraryCommand.cxx;hb=v2.8.8#l104 [^]
 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindLibraryCommand.cxx;hb=v2.8.8#l171 [^]

added way back when lots of platforms first started creating lib64 directories.

How does converting lib to lib64 prevent something in lib64 from being found?
(0030074)
Brad King   
2012-07-18 11:03   
Re 0013419:0030073: To answer my own question I missed your "...the output will show the path /var/lib/myproject being mangled to /var/lib64/myproject" explanation in the description.
(0030076)
Brad King   
2012-07-18 11:06   
I think what happens is that with CMAKE_FIND_ROOT_PATH set to /var/lib/myproject CMake generates search paths like

  /var/lib/myproject/usr/lib
  /var/lib/myproject/lib

First it tries the lib->lib64 variants

  /var/lib64/myproject/usr/lib64
  /var/lib64/myproject/lib64

and then it tries the normal variants

  /var/lib/myproject/usr/lib
  /var/lib/myproject/lib

which do not actually exist.
(0030077)
Brad King   
2012-07-18 11:08   
cmFindLibraryCommand::AddLib64Paths must be taught to incrementally replace one lib->lib64 at a time in the path and generate all combinations that exist. Moving to backlog until someone has time to do/contribute this.
(0030078)
Andy Piper   
2012-07-18 12:15   
Hi, Brad is correct in how the paths get mangled, but the value of CMAKE_FIND_ROOT_PATH is unimportant. I only used CMAKE_FIND_ROOT_PATH to make the bug-reproduction easier.

I've found that the bug is more generic: Any directory path with elements ending in "lib" are converted to "lib64", e.g. "foolib" -> "foolib64".

Sorry if my initial bug report wasn't clear enough.
(0030079)
Rolf Eike Beer   
2012-07-18 13:50   
But these directories should be searched with "lib" first, no?
(0030081)
Brad King   
2012-07-18 14:46   
Re 0013419:0030079: No, the lib64 paths come first. The transformation is only done when CMAKE_SIZEOF_VOID_P is 8. There is also a global property set by platform files to decide whether to do it at all (e.g. not for Debian systems). The proper fix is described in 0013419:0030077. It just makes the existing behavior robust to multiple instances of lib/ in one path.
(0030098)
Brad King   
2012-07-20 14:24   
I added a test case for lib->lib64 conversion cases:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1fe4b82a [^]

Then performed some refactoring and cleanup:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6ca2f82d [^]
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=54add62f [^]

Then implemented the approach in 0013419:0030077 for multiple instances of lib/:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=733726ed [^]

and activated the mixed-conversion test case.
(0032481)
Robert Maynard   
2013-03-04 08:38   
Closing resolved issues that have not been updated in more than 4 months.