MantisBT - CMake |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0012326 | CMake | CMake | public | 2011-07-09 14:03 | 2012-02-06 06:07 |
|
Reporter | Modestas Vainius | |
Assigned To | Brad King | |
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | |
Platform | amd64 | OS | Debian GNU/Linux | OS Version | sid |
Product Version | CMake 2.8.5 | |
Target Version | CMake 2.8.6 | Fixed in Version | CMake 2.8.6 | |
|
Summary | 0012326: [linux multiarch] /lib/<arch> is not in implicit link directories list |
Description | This is related to 0012037. CMake does not consider /lib/<arch> as implicit link directory as it's not in CMAKE_C_IMPLICIT_LINK_DIRECTORIES nor CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES. As a result, its sometimes (wrongly) adds /lib/<arch> to R(UN)PATH. I attach the patch which solves this issue. Not sure if it's a right way and if more path clean up calls are not needed.
By the way, what's more alarming is that solution proposed in http://public.kitware.com/Bug/view.php?id=11751#c25028 [^] will no longer work as CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES variable no longer has needed multiarch directories... However, it's too early to mess with CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES in Modules/Platform/UnixPath.cmake |
Steps To Reproduce | |
Additional Information | |
Tags | No tags attached. |
Relationships | related to | 0012037 | closed | Brad King | support multiarch lib paths for Debian/Ubuntu |
|
Attached Files | multiarch_lib_dirs_should_be_implicit.diff (1,127) 2011-07-09 14:03 https://public.kitware.com/Bug/file/3967/multiarch_lib_dirs_should_be_implicit.diff |
|
Issue History |
Date Modified | Username | Field | Change |
2011-07-09 14:03 | Modestas Vainius | New Issue | |
2011-07-09 14:03 | Modestas Vainius | File Added: multiarch_lib_dirs_should_be_implicit.diff | |
2011-07-25 13:21 | Brad King | Relationship added | related to 0012037 |
2011-07-25 13:28 | Brad King | Assigned To | => Brad King |
2011-07-25 13:28 | Brad King | Status | new => assigned |
2011-07-25 13:32 | Brad King | Note Added: 0027065 | |
2011-07-25 13:43 | Modestas Vainius | Note Added: 0027066 | |
2011-07-27 09:45 | Brad King | Note Added: 0027078 | |
2011-07-27 09:45 | Brad King | Status | assigned => resolved |
2011-07-27 09:45 | Brad King | Resolution | open => fixed |
2011-09-12 17:13 | David Cole | Fixed in Version | => CMake 2.8.6 |
2011-09-12 17:13 | David Cole | Target Version | => CMake 2.8.6 |
2012-02-06 06:07 | David Cole | Note Added: 0028502 | |
2012-02-06 06:07 | David Cole | Status | resolved => closed |
Notes |
|
(0027065)
|
Brad King
|
2011-07-25 13:32
|
|
How can the lib/<arch> directory not be in CMAKE_C_IMPLICIT_LINK_DIRECTORIES? We're detecting <arch> by looking for the lib/<arch> pattern in that variable.
The value of CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES is a hard-coded list of guesses that pre-dated the detected language-specific variable. The new one should contain everything because it is detected from the real toolchain. We kept the old one only for compatibility and "just in case". |
|
|
(0027066)
|
Modestas Vainius
|
2011-07-25 13:43
|
|
/usr/lib/<arch> is in CMAKE_C_IMPLICIT_LINK_DIRECTORIES, not /lib/<arch>. The rationale behind this is that development symlinks (*.so) are never in /lib. They are always in /usr/lib/<arch>/libname.so even if the library itself is in /lib/<arch>/. |
|
|
(0027078)
|
Brad King
|
2011-07-27 09:45
|
|
|
|
(0028502)
|
David Cole
|
2012-02-06 06:07
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|