MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005156CMakeCMakepublic2007-06-08 22:362016-06-10 14:30
ReporterGonzalo Garramuno 
Assigned ToBill Hoffman 
PriorityurgentSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0005156: FindLibrary is not respecting LD_LIBRARY_PATH
Description> echo $LD_LIBRARY_PATH
/usr/local/lib:/usr/lib:/lib:/usr/local/lib32/:/usr/lib32:/lib32

-- in a CMakeListst.txt file:

MESSAGE( STATUS ${CMAKE_SYSTEM_LIBRARY_PATH} )

-- /lib;/usr/lib;/usr/local/lib;/usr/lib/w32api;/usr/X11R6/lib;/usr/lib/X11;/opt/local/lib;/usr/pkg/lib;/opt/csw/lib;/opt/lib


Now, this seems pretty wrong.
On one hand, FIND_LIBRARY() seems never to actually consider LD_LIBRARY_PATH (albeit it considers LIB on windows).

CMAKE_SYSTEM_LIBRARY_PATH may be an LD_LIBRARY_PATH replacement, but it defines /usr/local/lib in what I'd consider the wrong order. That is, /usr/local/lib should take precedence over /usr/lib, as that's usually "local" user compiles.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files? UnixPaths.cmake (899) 1969-12-31 19:00
https://public.kitware.com/Bug/file/1031/UnixPaths.cmake
Issue History
Date ModifiedUsernameFieldChange
2007-08-28 13:27Philip LowmanNote Added: 0008713
2010-09-22 22:43Nathan Phillip Brink (binki)Note Added: 0022328
2010-11-09 22:47Philip LowmanNote Added: 0023118
2016-06-10 14:27Kitware RobotNote Added: 0041367
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:30Kitware RobotStatusresolved => closed

Notes
(0007864)
Gonzalo Garramuno   
2007-06-13 10:47   
New file, I removed the $ENV{LD_LIBRARY_PATH} to make it consistent with the include directories
(0008713)
Philip Lowman   
2007-08-28 13:27   
Do any other Unix build chains respect LD_LIBRARY_PATH in terms of searching for libraries at compile time? I was under the impression that LD_LIBRARY_PATH was only used at runtime.
(0022328)
Nathan Phillip Brink (binki)   
2010-09-22 22:43   
Other buildsystems just respect LDFLAGS within which -L flags may be added, enabling libraries to be found. LD_LIBRARY_PATH is not intended to be a buildsystem's library search path.
(0023118)
Philip Lowman   
2010-11-09 22:47   
To add additional library directories to the search path, CMake supports searching ${CMAKE_LIBRARY_PATH} as well as ${CMAKE_PREFIX_PATH}/lib (both as either CMake or environment variables).
http://www.cmake.org/Wiki/CMake_Useful_Variables#Environment_Variables [^]

Custom linker flags can be set with the LINK_FLAGS target property or via CMAKE_EXE_LINKER_FLAGS if they are executable specific. Also, CMake appears to support picking up the LDFLAGS environment variable (I am using 2.8.3)

$ export LDFLAGS=-HEY_I_WORK; cmake ..
$ make VERBOSE=1 |grep HEY_I_WORK
/usr/bin/c++ -HEY_I_WORK CMakeFiles/foo.dir/foo.cc.o -o foo -rdynamic
c++: unrecognized option '-HEY_I_WORK'

Furthermore, also mentioned in the bug report was CMAKE_SYSTEM_LIBRARY_PATH. I don't see /usr/lib or /usr/local/lib in here anymore on my Linux machine. In either case, /usr/local/lib appears to resolve library searches first (I'm using 2.8.3).

I suggest this issue be closed.
(0041367)
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.