May well be easier to switch from autoconf to cmake. The learning curve is far easier than autoconf.

So digging into this some more, this seems to be entirely vtk's fault. vtk indeed now inserts a version number at the end of the lib name /before/ the .so. To suppress this you can add -DVTK_CUSTOM_LIBRARY_SUFFIX='' in vtk's configure, but that of course leaves the package maintainers in the dilemma: if you suppress the ugly non-standard naming scheme, you break third-party software (like us) that expect vtk to be built in the default way. See a.o. this discussion https://bugs.archlinux.org/task/43378. So we should expect different distro's to have different solutions.

As far as I can see there's no way to find out how it's been build, even if we were using cmake. The value of VTK_CUSTOM_LIBRARY_SUFFIX that's been used isn't set in any of the cmake files that come with Debian's build for instance and neither is it in centos' rpm (which does set -DVTK_CUSOM_LIBRARY_SUFFIX=''" in the .spec of the source rpm).

That's a nice piece of blackmail then: use cmake as your build system and have code that will work with a script like

cmake_minimum_required(VERSION 2.6)
enable_language (Fortran CXX)
project(bob)
find_package(VTK REQUIRED)
include_directories(./include)
include(${VTK_USE_FILE})
add_executable(bob bob.cpp bob.F90)
target_link_libraries(bob ${VTK_LIBRARIES})

Otherwise, write an autoconf script to try every possibility of custom suffices.

And this is why I eventually gave up and started just using cmake for everything.

See the thing is - I don't see how it would work with cmake: as far as I can see you would have to know the setting for VTK_CUSTOM_LIBRARY_SUFFIX that was used. The accompanying cmake files just repeat the logic that if VTK_CUSTOM_LIBRARY_SUFFIX is not set, it defaults to $(VTK_MAJOR_VERSION)-$(VTK_MINOR_VERSION).

Kiteware maintain both vtk and cmake - and therefore insure that the "current" cmake supports the current VTK. If cmake is not detecting vtk it's typically because you have a older version of cmake relative to vtk.

Ah sorry I see now: I was looking in the wrong place. Yes, looks like that should just work indeed.

Ok, so what about this:

For include flags we run (from configure):

cmake --find-package -DNAME=VTK -DCOMPILER_ID=gcc -DLANGUAGE=Fortran -DMODE=COMPILE

and for lib flags:

cmake --find-package -DNAME=VTK -DCOMPILER_ID=gcc -DLANGUAGE=Fortran -DMODE=LINK

(substituting Fortran with CXX where appropriate).

After a little experimenting, @stephankramer's solution can be made robust for those with multiple installations by ensuring that VTK_DIR is set, either as an environment variable, or as a cmake macro

cmake --find-package -DVTK_DIR=/strange/path/to/library/cmake/files -DNAME=VTK -DCOMPILER_ID=gcc -DLANGUAGE=Fortran -DMODE=LINK

so I think it's a useful way to proceed, assuming that the extra graphical libraries it might pull in to link don't give people problems.

This is closed by #125, except in the various ways distributions have managed to break their own packages, which @tmbgreaves has discovered.

Is this issue fixed? I tried to build from the master branch and I'm getting stuck at this issue.

It's unfortunately somewhat distribution dependent, but in general you shouldn't be seeing that if you have cmake installed and it can find your VTK installation. (i.e. if
cmake --find-package -DNAME=VTK -DCOMPILER_ID=gcc -DLANGUAGE=Fortran -DMODE=LINK
returns something useful).