Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#43378 - [vtk] Libraries end with version number, not according to convention

Attached to Project: Community Packages
Opened by Ng Oon-Ee (ngoonee) - Thursday, 08 January 2015, 08:57 GMT
Last edited by Balló György (City-busz) - Wednesday, 24 January 2018, 05:38 GMT
Task Type General Gripe
Category Packages
Status Assigned   Reopened
Assigned To Anatol Pomozov (anatolik)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No


Current vtk package is full of libraries like /usr/lib/ etc.

This disallows linking vtk using -lvtkalglib as is common practice. Using -lvtkalglib-6.1 is a workaround but a slight hindrance when working between distros and OS.

Debian, at least, uses the (IMHO) more sane /usr/lib/ naming, as do most other libraries I'm aware off.

Additional info:
* package version(s)
This task depends upon

Comment by Ng Oon-Ee (ngoonee) - Thursday, 08 January 2015, 09:01 GMT
Having just checked Fedora's build for this (which also uses /usr/lib/ I think the difference is this flag:- -DVTK_CUSTOM_LIBRARY_SUFFIX=""
Comment by Ng Oon-Ee (ngoonee) - Thursday, 08 January 2015, 09:04 GMT
Oh, and while you're at it, would be good to also move include to /usr/include/vtk rather than /usr/include/vtk-6.1

Purely a gripe, this one wouldn't make as much of a difference as library naming.
Comment by Ray Rashif (schivmeister) - Thursday, 08 January 2015, 20:10 GMT
Hey Ng, thanks for reporting and the heads-up on the cmake flag. That certainly is non-standard practice but vtk is not the only one. However, you're right that this introduces an annoyance at build time and there is no benefit to keeping it this way.

If Andrzej doesn't get to it I'll make sure to see that the build sticks to upstream defaults, and if anything is out of the ordinary, we will be sure to file a ticket upstream and amend our build as necessary.

This one looks rather easily solvable but I'll prefer to update this along with or after the other less trivial vtk tickets have been resolved. Also, I think this is worthy of an upstream nudge.

Thanks for your continued support in testing this package!
Comment by Ng Oon-Ee (ngoonee) - Thursday, 08 January 2015, 21:44 GMT
I've actually found the solution to the compiler issue I've been having, will nudge upstream about it and post about it in the relevant bug report.
Comment by Ng Oon-Ee (ngoonee) - Thursday, 08 January 2015, 22:43 GMT
Oh, and I can confirm that the flag in my first comment works, since I've just re-compiled vtk with that change (among others). Didn't bother with the /usr/include one though.
Comment by Ng Oon-Ee (ngoonee) - Monday, 12 January 2015, 02:27 GMT
Scratch that, the libraries are named correctly but they still look for their old names, will be trying to dig into that.

EDIT: ah my bad, misread the messages. It was my pcl compile which hadn't been recompiled when I changed the library names. Ignore this message.

EDIT2: just an additional point to note that -DVTK_INSTALL_INCLUDE_DIR:PATH=include/vtk puts the headers in /usr/include/vtk.
Comment by Ng Oon-Ee (ngoonee) - Monday, 02 March 2015, 01:48 GMT
Just noticed vtk was recompiled but this bug was not addressed. Any particular reason?
Comment by Alex (nylocx) - Wednesday, 15 April 2015, 14:16 GMT
Would be nice if this could be adressed while updating vtk to the 6.2 release which is out for a while now.
Comment by Antonio Cervone (capitalaslash) - Wednesday, 30 September 2015, 14:28 GMT
  • Field changed: Percent Complete (100% → 0%)
vanilla version of the package should be preferred, external libraries expect vtk to be installed with its custom naming.
Comment by Antonio Cervone (capitalaslash) - Wednesday, 30 September 2015, 14:29 GMT
in fact, debian is not mangling the names in any way, check
Comment by Ray Rashif (schivmeister) - Wednesday, 30 September 2015, 19:53 GMT
Could anyone check if mayavi builds? I have no access to a build machine right now.

@Ng and @Alex, any opinions in light of what Antonio has brought up? See  FS#46431 .
Comment by Antonio Cervone (capitalaslash) - Thursday, 01 October 2015, 09:55 GMT
Comment by Anatol Pomozov (anatolik) - Thursday, 11 February 2016, 03:15 GMT
Is this issue resolved? I see that the lib names do not contain version

$ pacman -Ql vtk | grep libvtkalglib
vtk /usr/lib/
vtk /usr/lib/
Comment by Antonio Cervone (capitalaslash) - Thursday, 11 February 2016, 09:58 GMT
the version has been stripped from library names already in older version (via PKGBUILD), but the point is that this is not the way it should be.
vanilla vtk uses library version in library names and downstream software expects to find them.
Comment by Ray Rashif (schivmeister) - Thursday, 11 February 2016, 10:12 GMT
There are two ways to look at this: (i) writing your own code that links to vtk, (ii) using software which requires vtk. This gripe was filed with a focus on (i), but I can see why it might be a problem for (ii).

I say that if downstream software cannot find the proper libs, then either the downstream or upstream build system is fundamentally broken. In most cases pkg-config (whether by itself or via cmake) does a fine job.

The hack here could be reverted and a general complaint filed upstream, or the build could be made to yield /usr/lib/ naming (whether or not that requires a hack), which I believe would be much better.

I leave this up to Anatol now.
Comment by Antonio Cervone (capitalaslash) - Thursday, 11 February 2016, 10:46 GMT
the proper way to deal with this is convince upstream to properly name their libraries (by default).
that way any downstream software that wants to use vtk should adapt.