View Issue Details Jump to Notes ] Print ]
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.
TagsNo tags attached.
Attached Files? file icon UnixPaths.cmake [^] (899 bytes) 1969-12-31 19:00

 Relationships

  Notes
(0007864)
Gonzalo Garramuno (reporter)
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 (developer)
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) (reporter)
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 (developer)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2007-08-28 13:27 Philip Lowman Note Added: 0008713
2010-09-22 22:43 Nathan Phillip Brink (binki) Note Added: 0022328
2010-11-09 22:47 Philip Lowman Note Added: 0023118
2016-06-10 14:27 Kitware Robot Note Added: 0041367
2016-06-10 14:27 Kitware Robot Status assigned => resolved
2016-06-10 14:27 Kitware Robot Resolution open => moved
2016-06-10 14:30 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team