MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0009732CMakeCMakepublic2009-10-19 02:332012-03-09 08:48
ReporterPhaeodaria 
Assigned ToBrad King 
PrioritynormalSeveritytrivialReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0009732: Cmake does not disable Link Libray Dependencies in the project settings
DescriptionConfiguration Properties\Linker\Link Library Dependencies is true as default. With this setting Visual Studio/vcbuild automatically links all library dependencies. In addition to this CMake does link all dependencies too. All project are being linked twice and do generate linker errors.

I was able to resolve this issue by adding the following two lines to
cmLocalVisualStudio7Generator.cxx:cmLocalVisualStudio7GeneratorLinkFlagTable

  {"LinkLibraryDependencies", "LinkLibraryDependencies:NO", "disable link library dependencies", "FALSE", 0},
  {"LinkLibraryDependencies", "LinkLibraryDependencies:Yes", "enable link library dependencies", "TRUE", 0},

When generating the project with /LinkLibraryDependencies:NO in the linker flags the solution is begin generated Link Library Dependencies set to false and linking works fine.

I suggest to change the Visual Studio Generator in a way such that this is the default behaviour since CMake already handles dependencies.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0013032closed Kitware Robot Support the option "Use Library Dependency Inputs" in Visual Studio 2005+ 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2009-10-19 02:33PhaeodariaNew Issue
2009-10-19 08:09Bill HoffmanStatusnew => assigned
2009-10-19 08:09Bill HoffmanAssigned To => Brad King
2009-10-19 09:04Brad KingNote Added: 0018101
2009-10-19 09:04Brad KingStatusassigned => closed
2009-10-19 09:04Brad KingResolutionopen => fixed
2009-10-19 09:05Brad KingNote Added: 0018102
2009-10-19 09:05Brad KingStatusclosed => feedback
2009-10-19 09:05Brad KingResolutionfixed => reopened
2009-10-20 14:27PhaeodariaNote Added: 0018125
2009-10-20 14:57Brad KingNote Added: 0018126
2009-10-20 15:01PhaeodariaNote Added: 0018127
2009-10-20 15:33Brad KingNote Added: 0018128
2009-10-20 16:40Brad KingNote Added: 0018129
2009-10-20 17:33PhaeodariaNote Added: 0018133
2009-10-20 17:38Brad KingNote Added: 0018135
2009-10-21 07:49PhaeodariaNote Added: 0018138
2009-10-21 09:07Brad KingNote Added: 0018139
2009-10-21 12:28PhaeodariaNote Added: 0018145
2009-10-21 13:04Brad KingStatusfeedback => closed
2009-10-21 13:04Brad KingResolutionreopened => fixed
2012-03-09 08:48Brad KingRelationship addedrelated to 0013032

Notes
(0018101)
Brad King   
2009-10-19 09:04   
Please try the latest 2.8.0 release candidate. I believe this is already fixed. Re-open if not.
(0018102)
Brad King   
2009-10-19 09:05   
I take that back. I implemented the change once but never committed it to CVS. There are some problems with backwards compatibility.
(0018125)
Phaeodaria   
2009-10-20 14:27   
If there are compability issues this 'feature' it would be nice to activate it with a new flag similar to what I did to solve this problem temporary or by using a new cmake command which is used only for the visual studio generator.
(0018126)
Brad King   
2009-10-20 14:57   
I think the compatibility issues can be resolved with a little more work. AFAIK it only affects projects that use include_external_msproject() to bring in libraries and link to them. I don't want to create an extra API to enable something that should be the default.
(0018127)
Phaeodaria   
2009-10-20 15:01   
I added some external libs as targets, but I did not use include_external_msproject() in my project and encountered the problem.

Basically my project has one private.lib, one public.dll and multiple dlls/applications which link to public.dll. I had to break the CMake link chain to force CMake to link private.lib only to public.dll, but not down to any lib depending on public.dll which I could solve with the target_link_libraries variable.

Is there a workaround about the linker problem?
(0018128)
Brad King   
2009-10-20 15:33   
I meant that the compatibility problem is only for projects using include_external_msproject but just hard-coding LinkLibraryDependencies="false" works otherwise. However, it is possible some projects do

  add_library(foo ...)
  add_executable(bar ...)
  add_dependencies(bar foo) # Links in VS 8 & 9 but not elsewhere

and only care about VS 8 and 9. The last line should be target_link_libraries, but since the add_dependencies worked in previous CMakes for the use case, we have to be compatible. I'm investigating how to support this.

So, in your case you have

  add_library(private STATIC ...)
  add_library(public SHARED ...)
  target_link_libraries(public private)

  # Do not link private transitively through public
  set_property(TARGET public PROPERTY LINK_INTERFACE_LIBRARIES "")

  add_executable(app ...)
  target_link_libraries(app public) # don't want to link private

Does LinkLibraryDependencies break this? Doesn't it only link direct dependencies?
(0018129)
Brad King   
2009-10-20 16:40   
I decided to skip compatibility with the obscure VS 8&9 only projects. The commit below adds LinkLibraryDependencies="false" to all targets except those that have dependencies on targets created by include_external_msproject().

Do not link library dependencies in VS solutions
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio7Generator.h,v <-- Source/cmGlobalVisualStudio7Generator.h
new revision: 1.56; previous revision: 1.55
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio8Generator.cxx,v <-- Source/cmGlobalVisualStudio8Generator.cxx
new revision: 1.42; previous revision: 1.41
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio8Generator.h,v <-- Source/cmGlobalVisualStudio8Generator.h
new revision: 1.19; previous revision: 1.18
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudioGenerator.h,v <-- Source/cmGlobalVisualStudioGenerator.h
new revision: 1.15; previous revision: 1.14
/cvsroot/CMake/CMake/Source/cmLocalVisualStudio7Generator.cxx,v <-- Source/cmLocalVisualStudio7Generator.cxx
new revision: 1.257; previous revision: 1.256
/cvsroot/CMake/CMake/Source/cmVisualStudio10TargetGenerator.cxx,v <-- Source/cmVisualStudio10TargetGenerator.cxx
new revision: 1.20; previous revision: 1.19
(0018133)
Phaeodaria   
2009-10-20 17:33   
>,,,
> add_executable(app ...)
> target_link_libraries(app public) # don't want to link private
>
>Does LinkLibraryDependencies break this? Doesn't it only link direct >dependencies?

Since app depends on public VS linked public twice, one time using the CMake rule and one time because of link library dependencies.
(0018135)
Brad King   
2009-10-20 17:38   
Yes, but did that actually cause a failure?

Anyway, please try the latest CMake from CVS HEAD to see if it works for you.
(0018138)
Phaeodaria   
2009-10-21 07:49   
This caused a duplicate symbols linker error. I tested CVS HEADER and it works perfectly. Will this be included in the next CMake 2.8 release candidate?
(0018139)
Brad King   
2009-10-21 09:07   
I think the release manager has decided to include only fixes for regressions from previous CMake versions in the next 2.8.0 RC (rc3 introduced new breakage due to some insufficient testing of a fix, and he wants stability for the release). I've queued it for the 2.8 release branch, but it might not be in until 2.8.1.

Meanwhile, I can't reproduce a duplicate symbols link error using your public/private example. Can you please attach a minimal example that shows the problem? I want to reproduce it so I can write a regression test for this.
(0018145)
Phaeodaria   
2009-10-21 12:28   
I tried to write a small reproducer, but was not able to reproduce the problem in small. I've ported a big project with a lot of stuff inside, thus it's not easy to extract the essence which does produce the bug. Here's what I think is going on:

We generate a private.lib which uses a inline functions declared with __declspec(dllexport). We link private.lib to public.dll which uses the same functions. If an executable does link to private.lib and public.dll due to the visual studio library dependencies instead do of public.dll the linker complains with linker error 2005 that the symbols which are being used in private.lib are already defined in public.lib(public.dll).