0004529: Extra linked libs in CLIs on linux? - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0004529	Slicer4	Core: CLI infrastructure	public	2018-03-30 17:36	2018-03-31 14:23

Reporter	inorton	Assigned To	jcfr
Priority	normal	Severity	minor	Reproducibility	have not tried
Status	assigned	Resolution	open
Product Version
Target Version		Fixed in Version

Summary	0004529: Extra linked libs in CLIs on linux?
Description	In the 4.8.1 linux build, a number of CLIs are linked against libGL, libxcb, and other X- or graphics-related libraries which are typically not found on headless linux systems (such as lightweight docker images). Successfully running `CLI --help` for any of these requires installing >200MB of graphics libraries on ubuntu, for example. These may be pulled in by linking against (all of) VTK_LIBRARIES..
Steps To Reproduce	for f in `ls ./Slicer-4.8.1-linux-amd64/lib/Slicer-4.8/cli-modules/*`; do echo $f; ldd $f \| grep libGL; done (e.g. GrayscaleModelMaker [ProbeVolumeWithModel, IslandRemoval, MergeModels, several others)
Additional Information	For example, GrayscaleModelMaker pulls in both Qt and GLib: <pre> root@4603b44266e4:/usr/src# ldd ./Slicer-4.8.1-linux-amd64/lib/Slicer-4.8/cli-modules/GrayscaleModelMaker [..snip..] libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f14dd289000) libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007f14dd01a000) libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007f14dcda7000) libQtOpenGL.so.4 => /usr/src/Slicer-4.8.1-linux-amd64/lib/Slicer-4.8/libQtOpenGL.so.4 (0x00007f14dca9e000) libQtSql.so.4 => /usr/src/Slicer-4.8.1-linux-amd64/lib/Slicer-4.8/libQtSql.so.4 (0x00007f14dc85a000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f14dc655000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f14dc433000) libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f14dc231000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f14dbf20000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f14dbd06000) libfreetype.so.6 => not found libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f14dbafc000) libfontconfig.so.1 => not found libfontconfig.so.1 => not found libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f14db8d3000) libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f14db6d0000) libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0 (0x00007f14db4cd000) libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007f14db2c6000) libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1 (0x00007f14db0c3000) libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f14dae93000) libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f14dac90000) libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f14daa8a000) libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f14da888000) libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007f14da66f000) libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007f14da46a000) libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f14da264000) libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f14da053000) libfreetype.so.6 => not found libfontconfig.so.1 => not found libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f14d9e4f000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f14d9c49000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f14d99d9000) </pre>
Tags	No tags attached.

jcfr 2018-03-31 03:45 administrator ~0015641 Last edited: 2018-03-31 03:46 View 2 revisions	We should move the call to `find_package(VTK)` specifying just the required list of components. But before doing so, if my analysis of 2014 is still valid, it looks like we should update CTK to call `find_package(VTK ...)` from within CTKConfig. See http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=23413

jcfr 2018-03-31 03:54 administrator ~0015642	Reading some past discussion I had with Brad K., calling `find_package(VTK COMPONENTS ...)` multiple times in a row with a different set of components will break things. It means we should use the `vtk_module_config` macro provided by `vtkModuleAPI`: `find_package(VTK) vtk_module_config(MyVTKA a1 a2) vtk_module_config(MyVTKB b1 b2) ... use ${MyVTKA_LIBRARIES} and ${MyVTKB_LIBRARIES}` The list of components for each sub-directories, CLIs, etc .. could be obtained with the help of this script: https://github.com/Kitware/VTK/blob/master/Utilities/Maintenance/WhatModulesVTK.py

inorton 2018-03-31 08:31 developer ~0015646 Last edited: 2018-03-31 14:23 View 2 revisions	We should move the call to find_package(VTK) specifying just the required list of components. It means we should use the vtk_module_config macro provided by vtkModuleAPI I'm a little wary of that unless the "new" VTK module system does its resolution quite fast (edit: it looks like it does a similar recursion like ITK does: https://github.com/Kitware/VTK/blob/master/CMake/vtkModuleAPI.cmake). Right now a no-op reconfigure takes 2 min and spends most of the time in `find_package(ITK...)` (called 50 times).

Date Modified	Username	Field	Change
2018-03-30 17:36	inorton	New Issue
2018-03-30 17:36	inorton	Status	new => assigned
2018-03-30 17:36	inorton	Assigned To	=> jcfr
2018-03-30 17:37	inorton	Additional Information Updated	View Revisions
2018-03-30 17:37	inorton	Additional Information Updated	View Revisions
2018-03-31 03:45	jcfr	Note Added: 0015641
2018-03-31 03:46	jcfr	Note Edited: 0015641	View Revisions
2018-03-31 03:54	jcfr	Note Added: 0015642
2018-03-31 08:31	inorton	Note Added: 0015646
2018-03-31 14:23	inorton	Note Edited: 0015646	View Revisions