Arch Linux

Seems I missed it in the hdf5 rebuild, I'll get to it tomorrow.

There is an status update? Is there some way I can help? I'm anxiously waiting for the fix :)

I'm sorry to bother and thanks for the work with the package.

While waiting for the fix you can workaround it by creating a symbolic link to the new version. ie.

ln -s /usr/lib/libhdf5.so.100.0.0 /usr/lib/libhdf5.so.10

Just be sure to remove it before the fix! :)

poinu, please do not advise people do to really dumb things.

If you need a fix now, rebuild it yourself. It's not difficult, although I don't know what kind of resources this needs.

It wasn't supposed to be a solution whatsoever. Just a quick and dirty hack...

Symlinking libraries with different sonames (and thus versions) can seriously screw up your system. The soname (libfoo.so.10) is set by the upstream developer and if it changes that indicates that the library is NOT compatible with the older one. Don't do it. Never. Never ever. It's not a solution and not even a workaround.

A workaround is extracting the old library from the package and putting it into /usr/lib/. That's entirely fine apart from the fact that you then have an untracked file that will never be updated or remove, but it will not break stuff.

Another workaround is simply not updating the affected packages.

Got it. It's always good to learn new stuff, thanks for the explanation!

I've gone the hard way: compiling by myself. After two issues I've managed to do it successfully.

First, it does not even configure in order to generate the Makefiles. I've managed to fix this applying the following patch: https://gist.github.com/rafamanzo/2a6b86dc868e8bcd9394680db0174e1d

After that, XdmfH5Driver.cxx fails to compile at line 190. This is probably due to HDF5 new version incompatibility. I've "fixed" this one by modifying the PKGBUILD removing the HDF5 entry from the libs list (`for lib in `) that are used from the system.

Now, after installing, it is working for me the same way it was before :)

Ronald, what's the status of this? Did you just not get around to rebuilding it or are there any problems?

I'm rather busy with uni right now and forgot about this bug. Sorry.

Sorry I got busy as well after I found out it is not a quick fix. I was thinking about adding the old hdf5 package next to the current one (pytable doesn't go well against the new one as well it seems) for some time. I'll try to get to it in the next few days if no strange things come up.

I see an hdf5_18 package. I guess vtk6 should also use this, right? Do you want to do that or should I?

Yes, it was my intention (at first) to use the hdf5_18 package for this, but I'm struggling with it in addition to a lack of time. I suppose the vtk package has the same issue but the fix here should transfer over probably.

To make it work, we first need to patch the cmake stuff to recognize the hdf5_18 package instead of the normal hdf5 package. Then we still need to hdf5 dependency because of other features in vtk. I'm not sure if this will work out or not or this will give some strange internal version conflicts (as I have no knowledge of the vtk codebase). So, is the hdf5_18 package to correct way to fix this issue, I'm not sure.

Anyway, if you can provide any help that would be greatly appreciated.

Adding vtk maintainer as it also has libs linked to the old hdf5.

The Python bindings are also unusable due to this issue. Some of shared libs implementing Python modules, most notably vtk/vtkIOXdmf2Python.so, use libhdf5. Unfortunately, import vtk fails with an error that doesn't point to the libhdf5 issue, causing confusion:

$ python2 -c 'import vtk'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python2.7/site-packages/vtk/__init__.py", line 143, in <module>
from .vtkIOXdmf2 import *
File "/usr/lib/python2.7/site-packages/vtk/vtkIOXdmf2.py", line 9, in <module>
from vtkIOXdmf2Python import *
ImportError: No module named vtkIOXdmf2Python

$ ls -l /usr/lib/python2.7/site-packages/vtk/vtkIOXdmf2Python.so
-rwxr-xr-x 1 root root 6008 feb 17 22:28 /usr/lib/python2.7/site-packages/vtk/vtkIOXdmf2Python.so

$ ldd /usr/lib/python2.7/site-packages/vtk/vtkIOXdmf2Python.so | grep hdf5
libhdf5.so.10 => not found

I can hack around this by not loading the broken Python modules, but doing anything with Xdmf files requires hdf5.

Removing HDF5 at line 80 of PKGBUILD works fine for me. Here's a working PKGBUILD.

And the binary I've just built: http://chyen.twbbs.org/downloads/vtk6-6.3.0-3-x86_64.pkg.tar.xz.

"Removing HDF5 at line 80 of PKGBUILD works fine for me. Here's a working PKGBUILD."

That's still only a temporary measure, as it completely disables Xdmf support.

How to check the usability of Xdmf? I guess Xdmf is still working as now VTK is built against bundled HDF5 instead of the system HDF5.

I've pushed vtk6 6.3.0-4 to community-testing. It uses an internally built hdf5 which I think is fine for a legacy package.

@Anatol: I can't currently build vtk. Can you look into that? I'm not sure what is going on here.

==> Starting build()...
-- The C compiler identification is GNU 6.1.1
-- The CXX compiler identification is GNU 6.1.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Tclsh: /bin/tclsh (found version "8.6")
-- Found TCL: /usr/lib64/libtcl.so
-- Found TCLTK: /usr/lib64/libtcl.so
-- Found TK: /usr/lib64/libtk.so
-- Found Java: /usr/lib/jvm/default/bin/java (found version "1.7.0.101")
-- Found JNI: /usr/lib64/jvm/default/jre/lib/amd64/libjawt.so
-- Performing Test HAVE_GCC_ERROR_RETURN_TYPE
-- Performing Test HAVE_GCC_ERROR_RETURN_TYPE - Success
-- Performing Test HAVE_GCC_VISIBILITY
-- Performing Test HAVE_GCC_VISIBILITY - Success
CMake Error at CMake/vtkCompilerExtras.cmake:47 (if):
if given arguments:

"cc: error: ARGS: No such file or directory

cc (GCC) 6.1.1 20160707

Copyright (C) 2016 Free Software Foundation, Inc.

This is free software" " see the source for copying conditions. There is
NO

warranty" " not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.



" "VERSION_GREATER" "4.2.0" "AND" "BUILD_SHARED_LIBS" "AND"
"HAVE_GCC_VISIBILITY" "AND" "VTK_USE_GCC_VISIBILITY" "AND" "NOT" "MINGW"
"AND" "NOT" "CYGWIN"

Unknown arguments specified
Call Stack (most recent call first):
CMakeLists.txt:286 (include)


-- Configuring incomplete, errors occurred!

@bluewind I've had the same problem configuring VTK 7 two and a half months ago. I've posted here a patch that allowed me to compile it (https://gist.github.com/rafamanzo/2a6b86dc868e8bcd9394680db0174e1d) if you want, you can give it a try. I've been using this version I've compiled back then with no issues since then.

Secondly, can we expect a new fixed release for vtk (version 7 package) as well?

Thanks a lot!