View Issue Details Jump to Notes ] Print ]
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.
Attached Files

 Relationships

  Notes
(0030073)
Brad King (manager)
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 (manager)
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 (manager)
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 (manager)
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 (reporter)
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 (developer)
2012-07-18 13:50

But these directories should be searched with "lib" first, no?
(0030081)
Brad King (manager)
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 (manager)
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 (manager)
2013-03-04 08:38

Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2012-07-18 10:51 Andy Piper New Issue
2012-07-18 11:01 Brad King Note Added: 0030073
2012-07-18 11:03 Brad King Note Added: 0030074
2012-07-18 11:06 Brad King Note Added: 0030076
2012-07-18 11:08 Brad King Note Added: 0030077
2012-07-18 11:08 Brad King Status new => backlog
2012-07-18 12:15 Andy Piper Note Added: 0030078
2012-07-18 13:50 Rolf Eike Beer Note Added: 0030079
2012-07-18 14:46 Brad King Note Added: 0030081
2012-07-20 14:06 Brad King Assigned To => Brad King
2012-07-20 14:06 Brad King Status backlog => assigned
2012-07-20 14:24 Brad King Note Added: 0030098
2012-07-20 14:24 Brad King Status assigned => resolved
2012-07-20 14:24 Brad King Resolution open => fixed
2012-10-24 17:25 David Cole Fixed in Version => CMake 2.8.10
2012-10-24 17:25 David Cole Target Version => CMake 2.8.10
2013-03-04 08:38 Robert Maynard Note Added: 0032481
2013-03-04 08:38 Robert Maynard Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team