paraview superbuild issue - attribute cannot be used here: vtk::filepath


At my company, we are upgrading our custom application based on ParaView 5.9. to 5.10.1. I was able to successfully build it.

I started to update our “superbuild” (Paraview-super build fork) but I am having some weird compilation issues. It’s related to the new define VTK_FILEPATH

I get the following error :

cd /builds/superbuild/superbuild/paraview/build/VTK/Common/Core && /builds/superbuild/superbuild/paraview/build/bin/vtkWrapHierarchy-s3d @/builds/superbuild/superbuild/paraview/build/VTK/Common/Core/CMakeFiles/vtkCommonCore-hierarchy.Release.args -o /builds/superbuild/superbuild/paraview/build/lib/vtk/hierarchy/ParaView/vtkCommonCore-hierarchy.txt /builds/superbuild/superbuild/paraview/build/VTK/Common/Core/CMakeFiles/ @/builds/superbuild/superbuild/paraview/build/VTK/Common/Core/CMakeFiles/vtkCommonCore-hierarchy.depends.args
vtkWrapHierarchy-s3d: In /sources/specifx/VTK/Common/Core/vtkDynamicLoader.h:47: attribute cannot be used here: vtk::filepath

I saw that it was added in the following MR

Do I need to enable some custom CMake options through the superbuild ?


Hi Michal,

This error suggest that, in your superbuild, the vtkWrapHierarchy-s3d executable is out-of-date. Try an “ls -l” on it to make sure that it was recompiled when you did the build.

Hi, I’m working with @michal.wozniak (same company).

  1. we build inside a docker container, so everything should be freshly re-compiled
  2. I did a fresh clone of @michal.wozniak’s branch and launched the build (still inside docker, so it’s especially fresh :stuck_out_tongue: )

And I got the same error.

One important point is that we don’t get that error when building paraview by itself. We only get that error when building paraview using the superbuild.

We’ll continue to investigate.

Meanwhile, could you confirm my understanding?:

  1. The __VTK_WRAP__ macro should not be defined during normal compilation
  2. The __VTK_WRAP__ macro is defined inside vtk’s “compile tools” (which has it’s own bison/yacc parser, to parse the headers)
  3. [[vtk::filepath]] should only appear during wrapping (hence the macro VTK_FILEPATH)
  4. The error we have looks like the vtkWrapHierarchy-s3d doesn’t recognize the vtk::filepath attribute, even thought it should

Your understanding is correct on all points, but #4 is the critical one.

It looks like vtkWrapHierarchy doesn’t recognize the attribute. Which is why my first guess was that the vtkWrapHierarchy executable was an old one.

Another possibility is that something is causing problems with the parsing of vtkDynamicLoader.h. For example, maybe the superbuild is adding stuff to the include path that isn’t present in a stand-alone build. For example, maybe a header file somewhere has defined a macro with the name vtkLibHandle or OpenLibrary, and the error is a symptom of that. That’s just a wild guess, however.

And here’s something funny with your error. It complains about this header:


While it is running in this directory:


Do you have separate VTK and Paraview sources in your docker that aren’t in sync with each other?

I’ll verify what’s in the /builds/superbuild/superbuild/paraview/build/ directory.

It does look like the superbuild tries to build its own VTK :confused:

BTW, paraview has VTK as a git submodule, so yes, we have our own separate VTK (which builds correctly).

I’ll investigate, but VTK version mismatch is my only lead so far.

I confirm that we build the right VTK :confused:

We confirmed it in different ways, here is one:

I managed to get the build logs just for vtkWrapHierarchy-s3d (I build the docker in a way I could go inside and inspect/run stuff).

We can see that it builds from the /sources/... and it puts the object into the build directory, which is /builds/superbuild/superbuild/paraview/build/.

N.B. : current working directory is /builds/superbuild/superbuild/paraview/build/; and we use ninja as a generator

$ ninja vtkWrapHierarchy-s3d  -t clean
$ ninja vtkWrapHierarchy-s3d -v
[1/16] /usr/bin/cc -DWrappingTools_EXPORTS -IVTK/Wrapping/Tools -I/sources/specifx/VTK/Wrapping/Tools -fPIC  -O3 -DNDEBUG -fPIC -MD -MT VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseSystem.c.o -MF VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseSystem.c.o.d -o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseSystem.c.o -c /sources/specifx/VTK/Wrapping/Tools/vtkParseSystem.c
[2/16] /usr/bin/cc -DWrappingTools_EXPORTS -IVTK/Wrapping/Tools -I/sources/specifx/VTK/Wrapping/Tools -fPIC  -O3 -DNDEBUG -fPIC -MD -MT VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseMangle.c.o -MF VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseMangle.c.o.d -o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseMangle.c.o -c /sources/specifx/VTK/Wrapping/Tools/vtkParseMangle.c
[3/16] /usr/bin/cc -DWrappingTools_EXPORTS -DVTK_PARSE_VERSION=\"9.0\" -IVTK/Wrapping/Tools -I/sources/specifx/VTK/Wrapping/Tools -fPIC  -O3 -DNDEBUG -fPIC -MD -MT VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseMain.c.o -MF VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseMain.c.o.d -o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseMain.c.o -c /sources/specifx/VTK/Wrapping/Tools/vtkParseMain.c
[4/16] /usr/bin/cc -DWrappingTools_EXPORTS -IVTK/Wrapping/Tools -I/sources/specifx/VTK/Wrapping/Tools -fPIC  -O3 -DNDEBUG -fPIC -MD -MT VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseString.c.o -MF VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseString.c.o.d -o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseString.c.o -c /sources/specifx/VTK/Wrapping/Tools/vtkParseString.c
[5/16] /usr/bin/cc  -IVTK/Wrapping/Tools -I/sources/specifx/VTK/Wrapping/Tools -fPIC  -O3 -DNDEBUG -fPIE -MD -MT VTK/Wrapping/Tools/CMakeFiles/WrapHierarchy.dir/vtkWrapHierarchy.c.o -MF VTK/Wrapping/Tools/CMakeFiles/WrapHierarchy.dir/vtkWrapHierarchy.c.o.d -o VTK/Wrapping/Tools/CMakeFiles/WrapHierarchy.dir/vtkWrapHierarchy.c.o -c /sources/specifx/VTK/Wrapping/Tools/vtkWrapHierarchy.c
[6/16] /usr/bin/cc -DWrappingTools_EXPORTS -IVTK/Wrapping/Tools -I/sources/specifx/VTK/Wrapping/Tools -fPIC  -O3 -DNDEBUG -fPIC -MD -MT VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseMerge.c.o -MF VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseMerge.c.o.d -o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseMerge.c.o -c /sources/specifx/VTK/Wrapping/Tools/vtkParseMerge.c
[7/16] /usr/bin/cc -DWrappingTools_EXPORTS -IVTK/Wrapping/Tools -I/sources/specifx/VTK/Wrapping/Tools -fPIC  -O3 -DNDEBUG -fPIC -MD -MT VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseData.c.o -MF VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseData.c.o.d -o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseData.c.o -c /sources/specifx/VTK/Wrapping/Tools/vtkParseData.c
[8/16] /usr/bin/cc -DWrappingTools_EXPORTS -IVTK/Wrapping/Tools -I/sources/specifx/VTK/Wrapping/Tools -fPIC  -O3 -DNDEBUG -fPIC -MD -MT VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkWrap.c.o -MF VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkWrap.c.o.d -o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkWrap.c.o -c /sources/specifx/VTK/Wrapping/Tools/vtkWrap.c
[9/16] /usr/bin/cc -DWrappingTools_EXPORTS -IVTK/Wrapping/Tools -I/sources/specifx/VTK/Wrapping/Tools -fPIC  -O3 -DNDEBUG -fPIC -MD -MT VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseExtras.c.o -MF VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseExtras.c.o.d -o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseExtras.c.o -c /sources/specifx/VTK/Wrapping/Tools/vtkParseExtras.c
[10/16] /usr/bin/cc -DWrappingTools_EXPORTS -IVTK/Wrapping/Tools -I/sources/specifx/VTK/Wrapping/Tools -fPIC  -O3 -DNDEBUG -fPIC -MD -MT VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseHierarchy.c.o -MF VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseHierarchy.c.o.d -o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseHierarchy.c.o -c /sources/specifx/VTK/Wrapping/Tools/vtkParseHierarchy.c
[11/16] /usr/bin/cc -DWrappingTools_EXPORTS -IVTK/Wrapping/Tools -I/sources/specifx/VTK/Wrapping/Tools -fPIC  -O3 -DNDEBUG -fPIC -MD -MT VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkWrapText.c.o -MF VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkWrapText.c.o.d -o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkWrapText.c.o -c /sources/specifx/VTK/Wrapping/Tools/vtkWrapText.c
[12/16] /usr/bin/cc -DWrappingTools_EXPORTS -IVTK/Wrapping/Tools -I/sources/specifx/VTK/Wrapping/Tools -fPIC  -O3 -DNDEBUG -fPIC -MD -MT VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParsePreprocess.c.o -MF VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParsePreprocess.c.o.d -o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParsePreprocess.c.o -c /sources/specifx/VTK/Wrapping/Tools/vtkParsePreprocess.c
[13/16] /usr/bin/cc -DWrappingTools_EXPORTS -IVTK/Wrapping/Tools -I/sources/specifx/VTK/Wrapping/Tools -fPIC  -O3 -DNDEBUG -fPIC -MD -MT VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/ -MF VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/ -o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/ -c /sources/specifx/VTK/Wrapping/Tools/
[14/16] : && /usr/bin/cc -fPIC -fPIC  -O3 -DNDEBUG   -shared -Wl,-soname, -o lib/ VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/ VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseData.c.o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseExtras.c.o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseHierarchy.c.o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseMain.c.o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseMangle.c.o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseMerge.c.o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParsePreprocess.c.o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseString.c.o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParseSystem.c.o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkWrap.c.o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkWrapText.c.o  -Wl,-rpath,::::::: && :
[15/16] /usr/bin/cmake -E cmake_symlink_library lib/  lib/ lib/ && :
[16/16] : && /usr/bin/cc -fPIC  -O3 -DNDEBUG  VTK/Wrapping/Tools/CMakeFiles/WrapHierarchy.dir/vtkWrapHierarchy.c.o -o bin/vtkWrapHierarchy-s3d  -Wl,-rpath,"\$ORIGIN/../lib::::::::"  lib/ && :

P.S. specifx is the name of our fork of paraview, if you wondered

If you do something like ninja RenderingCore that build large chunks of VTK that don’t depend on wrapping, does that work? I’m just trying to figure out if the build issue is truly isolated to vtkWrapHierarchy.

Also, you say that you’re building your own fork of paraview. Does VTK’s paraview build?

ninja RenderingCore

I’ll try, with and without ninja -t clean.

Does VTK’s paraview build?

Yes, it does when we build paraview itself, without the superbuild.

I made a typo there, I meant “Kitware’s paraview”, not “VTK’s paraview”. I was just curious what was different between your fork and Paraview’s 5.10.1 release.

That worked.

$ ninja RenderingCore -t clean
$ ninja RenderingCore

Just to be extra sure, I’m running

$ ninja -t clean
$ ninja RenderingCore

EDIT: Worked too

I made a typo there, I meant “Kitware’s paraview”, not “VTK’s paraview”.

Ah, we don’t know yet, be we were going to try it :stuck_out_tongue:

I cloned KitWare’s ParaView, switched to 5.10.1 and used the superbuild to build it… and got the same error…

Nevermind, one path was still pointing at our fork.

Ok, I confirm that I have the same issue with ParaView…

I just finished a superbuild of 5.10.1 on my local system (ubuntu 22.04), and it didn’t give any errors.

cmake -G Ninja -DENABLE_python3=ON ../paraview-superbuild

What system and cmake configuration are you using?

I, too, just finished another build. Where I completely removed our code. And it built correctly. Sorry for the confusion.

So even though the path passed to cmake was pointing elsewhere (to ParaView), and I had cleaned up the build folder. It was somehow still referencing our fork.

One thing that might not have been clear: we also have a fork of VTK.

I checked that the VTK/Wrapping directory matches exactly what’s in ParaView’s VTK. But I haven’t checked all the differences in the whole repository.

I’ll try to build our VTK on its own, with and without wrapping. I’ll probably try building ParaView with our VTK and our fork of ParaView with ParaView’s VTK.

Since paraview 5.10.1 references VTK commit 481a2e778 a13117fb you should make sure that this commit SHA exists in your VTK fork.

Edit: oops, wrong SHA


Recently, another colleague make a package out of VTK… and added it to the docker

I found this:


And for sure…

$ ls /opt/vtk/lib | grep -i wrap

So the build configuration was all right, but at runtime vtkWrapHierarchy was using the wrong

(╯°□°)╯︵ ┻━┻

Thank you very much for trying to reproduce our problem

thanks a lot David for helping us

Ah. This is one of the reasons the vtkWrappingTools used to be statically linked. But the distro folks (debian, if I recall correctly) insisted that statically linked libraries were evil and had to be purged from all packages. Eventually I caved in.

How hard would it be to statically link it?

Like we already have our fork, we could maintain that on our own end. We’re going to have to manage different versions of VTK in any case, so if we could make our life easier by avoiding this kind of issue that would be great.

Also… are the vtkWrappingTools usually available from distro’s packages? I’m really wondering what were their reasoning behind insisting for dynamically linking something that is, as far as I know, just used at build-time?

P.S. My compliments on maintaining a Flex/Bison parser for C/C++ headers :laughing: