View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0012326CMakeCMakepublic2011-07-09 14:032012-02-06 06:07
ReporterModestas Vainius 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
Platformamd64OSDebian GNU/LinuxOS Versionsid
Product VersionCMake 2.8.5 
Target VersionCMake 2.8.6Fixed in VersionCMake 2.8.6 
Summary0012326: [linux multiarch] /lib/<arch> is not in implicit link directories list
DescriptionThis 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
TagsNo tags attached.
Attached Filesdiff file icon multiarch_lib_dirs_should_be_implicit.diff [^] (1,127 bytes) 2011-07-09 14:03 [Show Content]

 Relationships
related to 0012037closedBrad King support multiarch lib paths for Debian/Ubuntu 

  Notes
(0027065)
Brad King (manager)
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 (reporter)
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 (manager)
2011-07-27 09:45

Okay, that makes sense. Applied with minor formatting change:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=317d077f [^]

Thanks!
(0028502)
David Cole (manager)
2012-02-06 06:07

Closing resolved issues that have not been updated in more than 4 months.

 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


Copyright © 2000 - 2018 MantisBT Team