| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0015938 | CMake | CMake | public | 2016-01-28 04:30 | 2016-06-10 14:31 | ||||
| Reporter | Florian Rathgeber | ||||||||
| Assigned To | Kitware Robot | ||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||
| Status | closed | Resolution | moved | ||||||
| Platform | x86_64 | OS | CentOS | OS Version | 7.1 | ||||
| Product Version | CMake 3.4.3 | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0015938: RPATHs missing on link line for versioned libraries (.so.MAJOR.MINOR.PATCH) | ||||||||
| Description | When linking against a library using the *full path* to a *versioned* .so file, the RPATH (-Wl,-rpath,/full/path or equivalent) is missing from the link line. It *does* work when using the non-versioned library ending in .so | ||||||||
| Steps To Reproduce | Build CGAL 4.7, which exports libCGAL.so.11.0.1 as CGAL_LIBRARY in its CGALExports.cmake Use in your CMake project similar to the following: ... find_package( CGAL REQUIRED ) ... target_link_libraries( my_exe ${CGAL_LIBRARY} ) | ||||||||
| Additional Information | Looks like a "parser error" to me, potentially regex too narrow? | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files | |||||||||
| Relationships | |
| Relationships |
| Notes | |
|
(0040343) Brad King (manager) 2016-01-28 08:49 |
The recognition of shared libraries for use with RPATH is done here: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmComputeLinkInformation.cxx;hb=v3.4.3#l1825 [^] using a regex constructed here: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmComputeLinkInformation.cxx;hb=v3.4.3#l953 [^] It does not match versioned extensions because it is expected that development libraries (without version extension) are to be used when linking. The reason CGAL_LIBRARY is set to the implementation file with the version number is because CGALConfig.cmake incorrectly populates it using the LOCATION property. Given that CGALConfig.cmake is provided and includes CGALExports.cmake that means you're supposed to use imported targets like CGAL::CGAL instead: target_link_libraries( my_exe CGAL::CGAL ) |
|
(0040351) Florian Rathgeber (reporter) 2016-01-28 14:54 |
Brad, thanks for the detailed explanation! I agree with your suggested fix for our specific situation, however I still believe that linking against a versioned .so is a legitimate thing to do and therefore should work as expected. |
|
(0040357) Brad King (manager) 2016-01-29 09:29 |
Re 0015938:0040351: Yes, I think that would be reasonable. However, since the implementation file names can be arbitrary we may not be able to recognize them based on just the file name in general (numerical components are common but not required). When the named file already exists perhaps we could actually open it to detect whether it is a shared library or not, at least on ELF platforms. |
|
(0042923) Kitware Robot (administrator) 2016-06-10 14:29 |
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 |
| 2016-01-28 04:30 | Florian Rathgeber | New Issue | |
| 2016-01-28 08:49 | Brad King | Note Added: 0040343 | |
| 2016-01-28 14:54 | Florian Rathgeber | Note Added: 0040351 | |
| 2016-01-29 09:29 | Brad King | Note Added: 0040357 | |
| 2016-01-29 09:29 | Brad King | Status | new => backlog |
| 2016-06-10 14:29 | Kitware Robot | Note Added: 0042923 | |
| 2016-06-10 14:29 | Kitware Robot | Status | backlog => resolved |
| 2016-06-10 14:29 | Kitware Robot | Resolution | open => moved |
| 2016-06-10 14:29 | Kitware Robot | Assigned To | => Kitware Robot |
| 2016-06-10 14:31 | Kitware Robot | Status | resolved => closed |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |