Control: tags -1 wontfix Hello Peter,
Am Mittwoch, den 01.06.2016, 22:49 +0200 schrieb 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" > > but this file does not exist. Possible reasons include: > > > > 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. > 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. > 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.