Difference between revisions of "Documentation/Snapshot/Developers/Overlinking Underlinking"
| Line 26: | Line 26: | ||
== Should we avoid the use of {VTK,ITK}_LIBRARIES and specify dependency explicitly when developing libraries depending on these toolkit ? == | == Should we avoid the use of {VTK,ITK}_LIBRARIES and specify dependency explicitly when developing libraries depending on these toolkit ? == | ||
| − | + | === Reply from Ben Boeckel === | |
This would be the way I'd go. It reduces the amount of work the linker | This would be the way I'd go. It reduces the amount of work the linker | ||
| Line 42: | Line 42: | ||
both *nix and Win32 (not that familiar with Mac) as well that dashboards | both *nix and Win32 (not that familiar with Mac) as well that dashboards | ||
should test. | should test. | ||
| − | |||
== Should we update VTK, ITK, ... build system to understand the COMPONENT parameters of find_package ? == | == Should we update VTK, ITK, ... build system to understand the COMPONENT parameters of find_package ? == | ||
== Would it speed up the "fixup" of libraries when generating packages on Mac ? == | == Would it speed up the "fixup" of libraries when generating packages on Mac ? == | ||
Revision as of 17:38, 3 March 2012
Home < Documentation < Snapshot < Developers < Overlinking UnderlinkingContents
- 1 Hypothesis
- 2 Background
- 3 Questions
- 3.1 Should we use the --as-needed linker flags ? (see [1], [2], [3], [4]) ?
- 3.2 Should we avoid the use of {VTK,ITK}_LIBRARIES and specify dependency explicitly when developing libraries depending on these toolkit ?
- 3.3 Should we update VTK, ITK, ... build system to understand the COMPONENT parameters of find_package ?
- 3.4 Would it speed up the "fixup" of libraries when generating packages on Mac ?
Hypothesis
When building application on the top of our toolkits: VTK, ITK, etc ..
.... we usually rely on the CMake variable named: VTK_LIBRARIES, ITK_LIBRARIES, ...
This implies that every targets linked using these variables will be linked against the complete list of libraries.
Background
- While working on issue associated with ITK_AUTOLOAD_FACTORY, I noticed that using tool like ldd was systematically listing all VTK and ITK libraries to list dependency of a custom factory. Using the "-u" flag helps to find out which library are not direct dependency ... doing so just doesn't "feel" right and make the all process tedious and time consuming.
- Then, instead of trying to work around the "issue", I decided to communicate with the rest of the team to get a better understanding of what we should be doing and, by extension, what we should be recommending to developers outside Kitware.
Questions
Should we use the --as-needed linker flags ? (see [1], [2], [3], [4]) ?
- References:
[1] http://linux.die.net/man/1/ld [2] http://blog.flameeyes.eu/2009/07/01/does-as-needed-link-make-software-faster [3] http://www.gentoo.org/proj/en/qa/asneeded.xml [4] http://wiki.mandriva.com/en/Overlinking#Problems_introduced_by_--as-needed
Should we avoid the use of {VTK,ITK}_LIBRARIES and specify dependency explicitly when developing libraries depending on these toolkit ?
Reply from Ben Boeckel
This would be the way I'd go. It reduces the amount of work the linker needs to do and if dependencies grow, and it triggers a linker error instead of passing silently.
To fully do this, the libraries in VTK and ITK should specify target_link_libraries(lib LINK_INTERFACE_LIBRARIES ...) correctly so that transitive dependencies don't silently supply dependency growth as well. Newer versions of gcc and binutils are moving towards doing this by default, so running a dashboard on something with at least gcc 4.6 should help.
There's some slight differences between static and shared libraries on both *nix and Win32 (not that familiar with Mac) as well that dashboards should test.
