View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0014463 | CMake | (No Category) | public | 2013-10-08 12:15 | 2016-06-10 14:31 | ||||
Reporter | John Szwast | ||||||||
Assigned To | Kitware Robot | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | moved | ||||||
Platform | AMD64 | OS | Windows | OS Version | 7 | ||||
Product Version | CMake 2.8.11.2 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0014463: Linking fails with a gcc build with compound circular library dependencies. | ||||||||
Description | On a project with a library dependency cycle and a strict path of dependency, linking with gcc fails. | ||||||||
Steps To Reproduce | Attempt 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 Information | I'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. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | CMake MinGW MWE.zip [^] (3,946 bytes) 2013-10-08 12:15 | ||||||||
Relationships | |
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. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |