| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0005156 | CMake | CMake | public | 2007-06-08 22:36 | 2016-06-10 14:30 | ||||
| Reporter | Gonzalo Garramuno | ||||||||
| Assigned To | Bill Hoffman | ||||||||
| Priority | urgent | Severity | major | Reproducibility | always | ||||
| Status | closed | Resolution | moved | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0005156: 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. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files | |||||||||
| Relationships | |
| 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. |
| Notes |
| 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 |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |