View Issue Details Jump to Notes ] Print ]
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.
Attached Fileszip file icon CMake MinGW MWE.zip [^] (3,946 bytes) 2013-10-08 12:15

 Relationships

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

 Issue History
Date Modified Username Field Change
2013-10-08 12:15 John Szwast New Issue
2013-10-08 12:15 John Szwast File Added: CMake MinGW MWE.zip
2013-10-08 12:22 Brad King Additional Information Updated
2013-10-08 12:24 Brad King Note Added: 0034078
2013-10-08 12:57 John Szwast Note Added: 0034080
2013-10-08 13:20 Brad King Note Added: 0034081
2013-10-08 13:28 Brad King Note Added: 0034082
2016-06-10 14:29 Kitware Robot Note Added: 0042386
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team