Bug#826048: Faulty CMake file impairs compiling against GDCM

[Peter Mattern]

Source: gdcm
Version: 2.6.3-{6,5}
Severity: important

Compiling recent Ginkgo CADx against GDCM on Debian stretch yields two cmake warnings which
suggest there are corresponding errors in the packaging of GDCM.

-- The imported target "vtkgdcmsharpglue" references the file
"/usr/lib/x86_64-linux-gnu/libvtkgdcmsharpglue.so"
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"/usr/lib/x86_64-linux-gnu/gdcm-2.6/GDCMTargets.cmake"
but not all the files it references.

libvtkgdcmsharpglue.so is provided by package libvtkgdcm-cil but placed in
/usr/lib/cli/vtkgdcm-sharp-2.6/.

-- The imported target "vtkgdcmPython" references the file
"/usr/lib/python/dist-packages/libvtkgdcmPython.so"
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"/usr/lib/x86_64-linux-gnu/gdcm-2.6/GDCMTargets.cmake"
but not all the files it references.

libvtkgdcmPython.so isn't available any longer in stretch. It used to be provided in jessie
(GDCM 2.4.4) by package python-vtkgdcm in /usr/lib/python2.7/dist-packages/ where a library
libvtkgdcmPython.x86_64-linux-gnu.so can be found in stretch right now.

All findings are the same when the GDCM binary packages of stretch are replaced with their
counterparts from sid plus their additional new or changed dependencies.

The reason to assume it's a packaging issue in Debian is the fact that the warning messages
can not be seen when the same Ginkgo CADx checkout gets compiled against the same GDCM version
on Arch Linux where packaging does not involve any tweaking of GDCM's paths.

On a side note there's by default a bunch of similar messages, see attached ginkgo-vs-gdcm_cmake.txt,
which are simply due to the packages providing the missing files - libvtkgdcm2.6,
libvtkgdcm-java, python-vtkgdcm and libgdcm-tools - not being installed.
Just saying as I'm not sure whether it's alright to not have those files at hand by default.

-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

[Gert Wollny]

Control: tags -1 wontfix 

Hello Peter, 

Post by Peter Mattern
Source: gdcm
Version: 2.6.3-{6,5}
Severity: important
Compiling recent Ginkgo CADx against GDCM on Debian stretch yields two cmake warnings which
suggest there are corresponding errors in the packaging of GDCM.

-- The imported target "vtkgdcmsharpglue" references the file
  "/usr/lib/x86_64-linux-gnu/libvtkgdcmsharpglue.so"

This is to be expected. The problem is that gdcm references all
libraries within this cmake file, also those that may not be needed to
compile and link a program - e.g. Ginkgo doesn't need sharp or java
bindings related libraries. 

Post by Peter Mattern
The reason to assume it's a packaging issue in Debian is the fact
that the warning messages can not be seen when the same Ginkgo CADx
checkout gets compiled against the same GDCM version on Arch Linux
where packaging does not involve any tweaking of GDCM's paths.

AFAIK unlike in Debian, where we separate the original software into
different packages like -dev, -java, -cli, Arch Linux only provides one
package that contains everything that is build. Therefore, if something
is referenced in the according CMake file, then it is also installed. 

Since in Debian the libraries are separated into different packages one
solution to get cmake run without warnings would be to split the cmake-
targets file accordingly, and the other would be to always pull in all
library packages with the -dev package. The first one is an upstream
decision. We could do the latter, but usually this doesn't make much
sense, because for using GDCM with Java, Mono, or Python the -dev
package is not needed, and for compiling C++ code against GDCM the
language bindings are not needed. 

Post by Peter Mattern
Just saying as I'm not sure whether it's alright to not have those
files at hand by default.

It is completely alright as long as the dependent package does not
FTBFS. In fact you will see similar messages by other packages that use
CMake as build tool and provide these *target.cmake files (e.g. VTK).


Best, 
Gert

PS: I leave this open as wontfix because it is a common gotcha that
other might stumble upon. 

 

[Peter Mattern]

Thanks for your reply. But IMO it is missing the point.

Maybe we should first reconsider the workflow that takes place.
An application, here Ginkgo CADx, is sort of querying CMake like "Could you
please tell
me which library is providing feature foo?" and CMake replies "Sure. It's
library
/usr/lib/x86_64-linux-gnu/libFoo.so.".

Due to the sophisticated packaging in Debian it may very well happen that
libFoo.so isn't
accessible right when cmake gets invoked simply as the package providing
the library isn't
installed.
This is what I had in mind writing the "side note" in the initial posting
and what you
were referring to in your reply.

But the problem addressed in this report is CMake returning faulty paths or
files that aren't
available in the distribution at all besides they do belong to GDCM.
Could you by any chance have another look at the paragraphs after the two
messages above?
libvtkgdcmsharpglue.so *was installed* when cmake got invoked but wasn't
found as CMake didn't
know the correct path. libvtkgdcmPython.so *isn't available at all* in
stretch besides it is
basically part of GDCM. Apparently it was succeeded by
libvtkgdcmPython.x86_64-linux-gnu.so but
again CMake just isn't aware of this.
And both shouldn't happen, should it?

[Mathieu Malaterre]

Post by Peter Mattern
Thanks for your reply. But IMO it is missing the point.

No, Gert is right. This pattern is common to a lot of cmake-based
package. One need to break the monolithic installation mechanism
(single cmake entry point) to make it match the desired behavior for
Debian (a cmake file per binary package).

Another possible hack is to s/WARNING/STATUS/ the cmake GDCM package
(VTK used to do that), so that user(s) wont complain.

-M

[Gert Wollny]

Post by Peter Mattern
Thanks for your reply. But IMO it is missing the point.
 
But the problem addressed in this report is CMake returning faulty
paths or  files that aren't available in the distribution at all
besides they do belong to GDCM. Could you by any chance have another
look at the paragraphs after the two  messages above?
libvtkgdcmsharpglue.so *was installed* when cmake got invoked but
wasn't  found as CMake didn't know the correct path.

This is because the library is moved out of /usr/lib/<triplet> to a
gdcm specific path. It is not a library a third party is supposed to
link against. Locations for these packages are distribution specific,
because of this we cannot expect that upstream takes care of adjusting
the library path accordingly. At most they might consider in such cases
to not issue an entry in the cmake file at all, but most people use
cmake macros for library creation that would have to be adjusted for
each case and we can not expect that they think of this kind of
packaging issues that don't influence the functionality. 

Post by Peter Mattern
libvtkgdcmPython.so *isn't available at all* in 
stretch besides it is basically part of GDCM. Apparently it was
succeeded by  libvtkgdcmPython.x86_64-linux-gnu.so but
again CMake just isn't aware of this.

Same thing here, the package creates the library without the arch
specific suffix, but because the package supports multi-arch the name
of the library must be changed (Python modules don't have an arch
specific path),  and one should also not link to this library directly
it is only relevant for the gdcm Python module. 

Post by Peter Mattern
And both shouldn't happen, should it?

Granted, it doesn't look nice, but it is really not that important. 

Best, 
Gert