MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0014463CMake(No Category)public2013-10-08 12:152016-06-10 14:31
ReporterJohn Szwast 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformAMD64OSWindowsOS Version7
Product VersionCMake 2.8.11.2 
Target VersionFixed in Version 
Summary0014463: Linking fails with a gcc build with compound circular library dependencies.
DescriptionOn a project with a library dependency cycle and a strict path of dependency, linking with gcc fails.
Steps To ReproduceAttempt to build the attached example project with gcc.
The linker error will be of the form:

c\libc.a(c.obj):c.c:(.text+0xd): undefined reference to `do_b'
collect2.exe: error: ld returned 1 exit status
CMakeFiles\demo.dir\build.make:97: recipe for target 'demo.exe' failed
mingw32-make[2]: *** [demo.exe] Error 1
CMakeFiles\Makefile2:62: recipe for target 'CMakeFiles/demo.dir/all' failed
mingw32-make[1]: *** [CMakeFiles/demo.dir/all] Error 2
Makefile:74: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
Additional InformationI've encountered this with each of the following setups:
Windows 7 64-bit with CMake 2.8.11.2 using "MinGW Makefiles" generator.
Windows 7 64-bit with CMake 2.8.11.2 using "Ninja" generator.
Linux Mint 64-bit with CMake 2.8.9 using the default (Unix Makefiles) generator.

Each CMakeLists.txt file in the example project accurately specifies the libraries' dependencies with target_link_libraries() statements.

         c --> b
         ^     |
         |     v
demo --> d --> a
         ^     |
         |     |
         +-----+


The generated link command lists each pair of dependent libraries in the required order, but the whole dependency path of d -> c -> b -> a is not realized in the linker's library list order:

c:\MinGW\bin\gcc.exe -Wl,--whole-archive CMakeFiles\demo.dir/objects.a -Wl,--no-whole-archive -o demo.exe -Wl,--out-implib,libdemo.dll.a -Wl,--major-image-version,0,--minor-image-version,0 a\liba.a b\libb.a c\libc.a d\libd.a a\liba.a b\libb.a c\libc.a d\libd.a -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

So the parts of library a that are only used by b and not d are not available. And the part of b that does use library a isn't even getting linked in because the part of library c that uses it wasn't linked in yet when b's turn came around.
TagsNo tags attached.
Relationships
Attached Fileszip CMake MinGW MWE.zip (3,946) 2013-10-08 12:15
https://public.kitware.com/Bug/file/4894/*
Issue History
Date ModifiedUsernameFieldChange
2013-10-08 12:15John SzwastNew Issue
2013-10-08 12:15John SzwastFile Added: CMake MinGW MWE.zip
2013-10-08 12:22Brad KingAdditional Information Updatedbug_revision_view_page.php?rev_id=1279#r1279
2013-10-08 12:24Brad KingNote Added: 0034078
2013-10-08 12:57John SzwastNote Added: 0034080
2013-10-08 13:20Brad KingNote Added: 0034081
2013-10-08 13:28Brad KingNote Added: 0034082
2016-06-10 14:29Kitware RobotNote Added: 0042386
2016-06-10 14:29Kitware RobotStatusnew => 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
(0034078)
Brad King   
2013-10-08 12:24   
Try setting LINK_INTERFACE_MULTIPLICITY to >= 3 on one of the targets:

 http://www.cmake.org/cmake/help/v2.8.11/cmake.html#prop_tgt:LINK_INTERFACE_MULTIPLICITY [^]
(0034080)
John Szwast   
2013-10-08 12:57   
It works if I do it to one of the library targets but not to the executable target.
I would still prefer automatic linker command generation from the dependency information.
Thank you.
(0034081)
Brad King   
2013-10-08 13:20   
Re 0014463:0034080: CMake supports toolchains that have no --start-group/--end-group linker option so we must repeat the cycle some number of times. The number of times required can be arbitrarily high, limited only by the number of object files involved inside the archives. The default of 2 times works in most common cases. Only in very heavily inter-dependent cases like that you've encountered require more, and that is why we provide the LINK_INTERFACE_MULTIPLICITY setting.
(0034082)
Brad King   
2013-10-08 13:28   
Actually 2 times is enough for your project too, except that we need to tell CMake the right entry point into the cycle. We can get the order "d -> c -> b -> a" by telling CMake to start at d instead of a when entering the cycle. I can get your project to build without LINK_INTERFACE_MULTIPLICITY with a simple patch:

-target_link_libraries(demo a b c d)
+target_link_libraries(demo d)

This tells CMake that 'd' is the first member of the cycle from which a symbol will be needed. CMake uses that information to choose 'd' as the entry point and generates

 d a c b d a c b
(0042386)
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.