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 ?

Reply from Marcus D. Hanwell

I would go with updating the build system to understand the COMPONENT parameters of find_package, and is what we plan to do with VTK_LIBRARIES at least. I would be interested in what others think here, but this seems like the best interface, and it allows the developers of these libraries some room to adjust the linked libraries if needed for certain special cases.

When using exported targets the use of explicit linking is also a very good approach, and so it may be a case of deciding on the best fit between these two approaches in my opinion.

Reply from Stephen Aylward

+1 to Marcus' idea

Keep in mind that ITKv4 potentially has a huge number of libraries due to modularization. You don't want to manage them manually. ITK_LIBRARIES or the (is this working yet?) COMPONENT parameter are the best bets that I know of.

Reply from Brad King

ITKv4's modularization infrastructure will already set ITK_LIBRARIES based on the find_package COMPONENTS arguments.

Useful script

I just created a small project hosting a convenient script that allow to ...

... discover on which toolkit (ITK, CTK or VTK) you cpp project is depending on.

See https://github.com/jcfr/HeaderToolkitDependencyWalker