MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0014684CMakeCMakepublic2014-01-06 08:342016-06-10 14:31
ReporterClinton Stimpson 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionmoved 
PlatformLinuxOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0014684: Missing -rpath-link with static library in mix
DescriptionUsing attached project, I get a link error:
/usr/bin/ld: warning: libshareda.so, needed by .../build/subdir/libsharedb.so, not found (try using -rpath or -rpath-link)
.../build/subdir/libsharedb.so: undefined reference to `shareda()'


Somehow a needed -rpath-link is dropped instead of pushed through the usage of a static library.

This was found when some newer Linux distributions have the --as-needed linker flag on by default.
I added the --no-undefined linker flag to help show that the bug isn't in the code.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesgz test-rpath-link.tar.gz (770) 2014-01-06 08:34
https://public.kitware.com/Bug/file/5039/test-rpath-link.tar.gz
Issue History
Date ModifiedUsernameFieldChange
2014-01-06 08:34Clinton StimpsonNew Issue
2014-01-06 08:34Clinton StimpsonFile Added: test-rpath-link.tar.gz
2014-01-06 10:10Brad KingNote Added: 0034910
2014-01-11 01:10Clinton StimpsonNote Added: 0034924
2014-01-13 11:25Brad KingNote Added: 0034931
2014-01-13 11:25Brad KingStatusnew => backlog
2016-06-10 14:29Kitware RobotNote Added: 0042459
2016-06-10 14:29Kitware RobotStatusbacklog => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0034910)
Brad King   
2014-01-06 10:10   
The rpath-link flag is used when cmComputeLinkDepends::FollowSharedDeps walks shared library dependencies. Something may be cutting the walk off at the static library. However, cmComputeLinkDepends does not test whether a target is shared or not itself. It uses the cmTarget::GetLinkInterface result. Further investigation will be needed.
(0034924)
Clinton Stimpson   
2014-01-11 01:10   
I've narrowed this down to cmTarget.cxx line 5400 where it filters out static libraries.

              if(tgt->GetType() == cmTarget::SHARED_LIBRARY)
                {
                iface.SharedDeps.push_back(*li);
                }

If I go ahead and add the static library to SharedDeps, it fixes this problem.
But, it doesn't look like the right fix, and I assume at this point we need to follow static libraries recursively to add dependent shared libraries to the SharedDeps list.


The attached example can be modified to include the following for a more complete test.

install(TARGETS shared2 sharedb shareda EXPORT exp
  RUNTIME DESTINATION lib
  LIBRARY DESTINATION lib )
export(EXPORT exp FILE ${CMAKE_CURRENT_BINARY_DIR}/exp.cmake)
(0034931)
Brad King   
2014-01-13 11:25   
We already follow the link implementation recursively to identify the list of compilation languages used. See cmTarget::GetLinkClosure. Near the block you quote in 0014684:0034924 the impl->Languages is also used. The proper fix may be to teach GetLinkClosure to also handle SharedDeps and then use that instead of GetLinkImplementation to collect iface.SharedDeps.
(0042459)
Kitware Robot   
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.