Compiling recent Ginkgo CADx against GDCM on Debian stretch yields two cmake warnings which suggest there are corresponding errors in the packaging of GDCM. libvtkgdcmsharpglue.so is provided by package libvtkgdcm-cil but placed in /usr/lib/cli/vtkgdcm-sharp-2.6/. 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.
Hello Peter, Am Mittwoch, den 01.06.2016, 22:49 +0200 schrieb Peter Mattern: 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. 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. 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.
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?
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.
Am Donnerstag, den 02.06.2016, 01:34 +0200 schrieb Peter Mattern: 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. 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. Granted, it doesn't look nice, but it is really not that important. Best, Gert
I'm not 100% sure if this is the same issue I'm having but I think
so, so I' commenting here instead of opening a new one.
The following was working fine in Debian Wheezy and returned the
expected lib flags:
cmake --find-package \
-DNAME=GDCM \
-DCOMPILER_ID=GNU \
-DLANGUAGE=CXX \
-DMODE=LINK
However, it now returns nothing. The above incantation is what the
autoconf CMAKE_FIND_PACKAGE would do. Did I understood correctly
that the above is not always expected to work in Debian? If so,
what should be used instead?
Thank you
Carnë Draug
Control: tags -1 moreinfo Does it work if you change into -DMODE=COMPILE ?
Yes. Getting the compile flags works fine:
$ cmake --find-package \
-DNAME=GDCM \
-DCOMPILER_ID=GNU \
-DLANGUAGE=CXX \
-DMODE=COMPILE
-I/usr/include/gdcm-2.6
$ cmake --find-package \
-DNAME=GDCM \
-DCOMPILER_ID=GNU \
-DLANGUAGE=CXX \
-DMODE=LINK
The last command, -DMODE=LINK, simply returns an empty line.
Well it is in fact returning an empty string, so I would not consider this a bug. As far as I understand the link line for GDCM should not add anything. In the past (previous cmake version) it used to return "-rdynamic". That does not seems required anymore. GDCM libs are installed in the default path, so your linker should be able to find them without tweaking the link line.
I could swear that in Wheezy this also returned all the multiple -lgdcm* but after I checked I was wrong. Indeed it only returned -rdynamic. Thank you for the attention and apologies for all the noise.
Mrs. Victoria Marcus ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Mrs. Victoria Marcus ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Hello, You have a Donation. And one more thing, this donation is made out to you as to enable you generously help me extend hands of giving to the less privilege, orphans and charity organizations within your locality. your urgent response will be Appreciated Good-luck.
Greeting to you, I'm Maria Luiza Lopes by name, Mrs. Victoria picked you for Donation project. Contact her via; Mrs.victoria.marcus@outlook.com<mailto:Mrs.victoria.marcus@outlook.com> for details Kind regards Do not reply back contact her email for claims : Mrs.victoria.marcus@outlook.com<mailto:Mrs.victoria.marcus@outlook.com> Good-Luck
My private email addreess: jung.yoon0147@gmail.com<mailto:jung.yoon0147@gmail.com> hope to read from you shortly. Regards, Mr. Jung Yoon. Head Of Operations.
-- Please can we talk?? Something Just Came Up and It Is Very Urgent , Please I Need Your Attention. Regard.