View Issue Details [ Jump to Notes ] [ Print ]
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.
TagsNo tags attached.
Attached Files

 Relationships
related to 0013032closedKitware Robot Support the option "Use Library Dependency Inputs" in Visual Studio 2005+ 

  Notes
(0018101)
Brad King (manager)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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).

 Issue History
Date Modified Username Field Change
2009-10-19 02:33 Phaeodaria New Issue
2009-10-19 08:09 Bill Hoffman Status new => assigned
2009-10-19 08:09 Bill Hoffman Assigned To => Brad King
2009-10-19 09:04 Brad King Note Added: 0018101
2009-10-19 09:04 Brad King Status assigned => closed
2009-10-19 09:04 Brad King Resolution open => fixed
2009-10-19 09:05 Brad King Note Added: 0018102
2009-10-19 09:05 Brad King Status closed => feedback
2009-10-19 09:05 Brad King Resolution fixed => reopened
2009-10-20 14:27 Phaeodaria Note Added: 0018125
2009-10-20 14:57 Brad King Note Added: 0018126
2009-10-20 15:01 Phaeodaria Note Added: 0018127
2009-10-20 15:33 Brad King Note Added: 0018128
2009-10-20 16:40 Brad King Note Added: 0018129
2009-10-20 17:33 Phaeodaria Note Added: 0018133
2009-10-20 17:38 Brad King Note Added: 0018135
2009-10-21 07:49 Phaeodaria Note Added: 0018138
2009-10-21 09:07 Brad King Note Added: 0018139
2009-10-21 12:28 Phaeodaria Note Added: 0018145
2009-10-21 13:04 Brad King Status feedback => closed
2009-10-21 13:04 Brad King Resolution reopened => fixed
2012-03-09 08:48 Brad King Relationship added related to 0013032

Copyright © 2000 - 2018 MantisBT Team