Documentation/Snapshot/Developers/Overlinking Underlinking

From Slicer Wiki
Jump to: navigation, search
Home < Documentation < Snapshot < Developers < Overlinking Underlinking

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.


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 ?