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

**URL:** https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760
**Category:** ParaView Support
**Created:** [March 29, 2023, 7:59pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760 "2023-03-29T19:59:40Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![michal.wozniak](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/m/848f3c/32.png) [@michal.wozniak](https://discourse.paraview.org/u/michal.wozniak)
#### Post date: [March 29, 2023, 7:59pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/1 "2023-03-29T19:59:40Z")

</div>

Hi,

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 :

```auto
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/vtkCommonCore-hierarchy.data @/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 [https://gitlab.kitware.com/vtk/vtk/-/merge\_requests/8290](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8290)

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

thanks

---

<div class="post-metadata">

### Author: ![dgobbi](https://discourse.paraview.org/user_avatar/discourse.paraview.org/dgobbi/32/11302_2.png) [@dgobbi](https://discourse.paraview.org/u/dgobbi)
#### Post date: [March 30, 2023, 12:09pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/2 "2023-03-30T12:09:51Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![fstamour](https://discourse.paraview.org/user_avatar/discourse.paraview.org/fstamour/32/5305_2.png) [@fstamour](https://discourse.paraview.org/u/fstamour)
#### Post date: [March 30, 2023, 3:03pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/3 "2023-03-30T15:03:16Z")

</div>

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 😛 )

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

---

<div class="post-metadata">

### Author: ![dgobbi](https://discourse.paraview.org/user_avatar/discourse.paraview.org/dgobbi/32/11302_2.png) [@dgobbi](https://discourse.paraview.org/u/dgobbi)
#### Post date: [March 30, 2023, 4:15pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/4 "2023-03-30T16:15:05Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![dgobbi](https://discourse.paraview.org/user_avatar/discourse.paraview.org/dgobbi/32/11302_2.png) [@dgobbi](https://discourse.paraview.org/u/dgobbi)
#### Post date: [March 30, 2023, 4:19pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/5 "2023-03-30T16:19:35Z")

</div>

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

```cpp
/sources/specifx/VTK/Common/Core/vtkDynamicLoader.h

```

While it is running in this directory:

```cpp
/builds/superbuild/superbuild/paraview/build/VTK/Common/Core

```

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

---

<div class="post-metadata">

### Author: ![fstamour](https://discourse.paraview.org/user_avatar/discourse.paraview.org/fstamour/32/5305_2.png) [@fstamour](https://discourse.paraview.org/u/fstamour)
#### Post date: [March 30, 2023, 5:30pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/6 "2023-03-30T17:30:34Z")

</div>

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 😕

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.

---

<div class="post-metadata">

### Author: ![fstamour](https://discourse.paraview.org/user_avatar/discourse.paraview.org/fstamour/32/5305_2.png) [@fstamour](https://discourse.paraview.org/u/fstamour)
#### Post date: [March 30, 2023, 6:41pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/7 "2023-03-30T18:41:13Z")

</div>

I confirm that we build the right VTK 😕

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

```auto
$ 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/vtkParse.tab.c.o -MF VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParse.tab.c.o.d -o VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParse.tab.c.o -c /sources/specifx/VTK/Wrapping/Tools/vtkParse.tab.c
[14/16] : && /usr/bin/cc -fPIC -fPIC -O3 -DNDEBUG -shared -Wl,-soname,libvtkWrappingTools-s3d.so.1 -o lib/libvtkWrappingTools-s3d.so.5.11 VTK/Wrapping/Tools/CMakeFiles/WrappingTools.dir/vtkParse.tab.c.o 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/libvtkWrappingTools-s3d.so.5.11 lib/libvtkWrappingTools-s3d.so.1 lib/libvtkWrappingTools-s3d.so && :
[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/libvtkWrappingTools-s3d.so.5.11 && :

```

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

---

<div class="post-metadata">

### Author: ![dgobbi](https://discourse.paraview.org/user_avatar/discourse.paraview.org/dgobbi/32/11302_2.png) [@dgobbi](https://discourse.paraview.org/u/dgobbi)
#### Post date: [March 30, 2023, 6:52pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/8 "2023-03-30T18:52:15Z")

</div>

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?

---

<div class="post-metadata">

### Author: ![fstamour](https://discourse.paraview.org/user_avatar/discourse.paraview.org/fstamour/32/5305_2.png) [@fstamour](https://discourse.paraview.org/u/fstamour)
#### Post date: [March 30, 2023, 6:54pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/9 "2023-03-30T18:54:13Z")

</div>

> 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.

---

<div class="post-metadata">

### Author: ![dgobbi](https://discourse.paraview.org/user_avatar/discourse.paraview.org/dgobbi/32/11302_2.png) [@dgobbi](https://discourse.paraview.org/u/dgobbi)
#### Post date: [March 30, 2023, 7:00pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/10 "2023-03-30T19:00:53Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![fstamour](https://discourse.paraview.org/user_avatar/discourse.paraview.org/fstamour/32/5305_2.png) [@fstamour](https://discourse.paraview.org/u/fstamour)
#### Post date: [March 30, 2023, 7:01pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/11 "2023-03-30T19:01:43Z")

</div>

That worked.

```auto
$ ninja RenderingCore -t clean
$ ninja RenderingCore

```

Just to be extra sure, I’m running

```auto
$ 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 😛

---

<div class="post-metadata">

### Author: ![fstamour](https://discourse.paraview.org/user_avatar/discourse.paraview.org/fstamour/32/5305_2.png) [@fstamour](https://discourse.paraview.org/u/fstamour)
#### Post date: [March 31, 2023, 3:31pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/12 "2023-03-31T15:31:46Z")

</div>

~~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.

---

<div class="post-metadata">

### Author: ![fstamour](https://discourse.paraview.org/user_avatar/discourse.paraview.org/fstamour/32/5305_2.png) [@fstamour](https://discourse.paraview.org/u/fstamour)
#### Post date: [March 31, 2023, 4:25pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/13 "2023-03-31T16:25:18Z")

</div>

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

---

<div class="post-metadata">

### Author: ![dgobbi](https://discourse.paraview.org/user_avatar/discourse.paraview.org/dgobbi/32/11302_2.png) [@dgobbi](https://discourse.paraview.org/u/dgobbi)
#### Post date: [March 31, 2023, 4:48pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/14 "2023-03-31T16:48:49Z")

</div>

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

```plaintext
cmake -G Ninja -DENABLE_python3=ON ../paraview-superbuild
ninja

```

What system and cmake configuration are you using?

---

<div class="post-metadata">

### Author: ![fstamour](https://discourse.paraview.org/user_avatar/discourse.paraview.org/fstamour/32/5305_2.png) [@fstamour](https://discourse.paraview.org/u/fstamour)
#### Post date: [March 31, 2023, 5:08pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/15 "2023-03-31T17:08:52Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![dgobbi](https://discourse.paraview.org/user_avatar/discourse.paraview.org/dgobbi/32/11302_2.png) [@dgobbi](https://discourse.paraview.org/u/dgobbi)
#### Post date: [March 31, 2023, 5:28pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/16 "2023-03-31T17:28:23Z")

</div>

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

---

<div class="post-metadata">

### Author: ![fstamour](https://discourse.paraview.org/user_avatar/discourse.paraview.org/fstamour/32/5305_2.png) [@fstamour](https://discourse.paraview.org/u/fstamour)
#### Post date: [March 31, 2023, 5:55pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/17 "2023-03-31T17:55:54Z")

</div>

Sooooo…

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

I found this:

```auto
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/opt/vtk/lib"

```

And for sure…

```auto
$ ls /opt/vtk/lib | grep -i wrap
libvtkWrappingPythonCore3.7-s3d.so
libvtkWrappingPythonCore3.7-s3d.so.1
libvtkWrappingPythonCore3.7-s3d.so.9.0.20201030
libvtkWrappingTools-s3d.so
libvtkWrappingTools-s3d.so.1
libvtkWrappingTools-s3d.so.9.0.20201030

```

So the build configuration was all right, but at runtime `vtkWrapHierarchy` was using the wrong `libvtkWrappingTools-s3d.so`.

(╯°□°）╯︵ ┻━┻

Thank you very much for trying to reproduce our problem

---

<div class="post-metadata">

### Author: ![michal.wozniak](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/m/848f3c/32.png) [@michal.wozniak](https://discourse.paraview.org/u/michal.wozniak)
#### Post date: [March 31, 2023, 5:56pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/18 "2023-03-31T17:56:40Z")

</div>

thanks a lot David for helping us

---

<div class="post-metadata">

### Author: ![dgobbi](https://discourse.paraview.org/user_avatar/discourse.paraview.org/dgobbi/32/11302_2.png) [@dgobbi](https://discourse.paraview.org/u/dgobbi)
#### Post date: [March 31, 2023, 6:01pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/19 "2023-03-31T18:01:03Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![fstamour](https://discourse.paraview.org/user_avatar/discourse.paraview.org/fstamour/32/5305_2.png) [@fstamour](https://discourse.paraview.org/u/fstamour)
#### Post date: [March 31, 2023, 6:09pm UTC](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760/20 "2023-03-31T18:09:54Z")

</div>

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 😆

[Next page](https://discourse.paraview.org/t/paraview-superbuild-issue-attribute-cannot-be-used-here-vtk-filepath/11760.md?page=2)