# Cmake error with add\_subdirectory in plugin
**URL:** https://discourse.paraview.org/t/cmake-error-with-add-subdirectory-in-plugin/12717
**Category:** Development
**Created:** [August 18, 2023, 5:22pm UTC](https://discourse.paraview.org/t/cmake-error-with-add-subdirectory-in-plugin/12717 "2023-08-18T17:22:20Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@zetwal](https://discourse.paraview.org/u/zetwal)
#### Post date: [August 18, 2023, 5:22pm UTC](https://discourse.paraview.org/t/cmake-error-with-add-subdirectory-in-plugin/12717/1 "2023-08-18T17:22:20Z")
Hello
I’m working on a plugin for a reader (GenericIO) that depends on other libraries (blosc and SZ). So, in the CMakeLists.txt, I have add\_subdirectory(GIO/thirdparty), where blosc is found. Part of the CMakelists.txt there is as follows:
```auto
add_library(compression STATIC ${BLOSC_Sources} ${SZ_Sources})
set_property(TARGET compression PROPERTY C_STANDARD 99)
target_include_directories(compression PRIVATE ${BLOSC_include_dirs} ${SZ_include_dirs})
target_include_directories(compression INTERFACE
blosc
SZ/sz/include
)
target_compile_definitions(compression PRIVATE HAVE_LZ4 HAVE_SNAPPY HAVE_ZLIB HAVE_ZSTD)
if(OpenMP_FOUND)
target_link_libraries(compression PRIVATE OpenMP::OpenMP_C OpenMP::OpenMP_CXX)
endif()
```
and then the main CMakeLists: has target\_link\_libraries(LANL\_GenericIO PRIVATE compression). Whenever I run cmake, I get:
> CMake Error: install(EXPORT “GenericIOReader” …) includes target “LANL\_GenericIO” which requires target “compression” that is not in any export set.
>
> CMake Error in Plugins/GenericIOReader/CMakeLists.txt:
> export called with target “LANL\_GenericIO” which requires target
> “compression” that is not in any export set.
What could I be doing wrong? This is based on [CMakeLists.txt · octree · hacc / GenericIO · GitLab](https://git.cels.anl.gov/hacc/genericio/-/blob/octree/CMakeLists.txt) where there are no issues in the CMake.
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [August 18, 2023, 10:30pm UTC](https://discourse.paraview.org/t/cmake-error-with-add-subdirectory-in-plugin/12717/2 "2023-08-18T22:30:30Z")
The CMake code for `GIO/thirdparty` needs to work with the way we export symbols from ParaView. This is usually as easy as `_vtk_module_apply_properties(tgtname)` and `_vtk_module_install(tgtname)`.
Note that if this is intended for ParaView itself, we have other, preferred mechanisms, for dealing with third party code. Ideally it would just be `find_package(blosc)` and `find_package(sz)` and using the targets they provide, but failing that, these will need their symbols mangled as we build `blosc` as part of the ParaView Superbuild for ADIOS and if the symbols are the same name, we’re asking for trouble when this plugin is loaded.
---
### Author:  [@zetwal](https://discourse.paraview.org/u/zetwal)
#### Post date: [August 21, 2023, 1:37am UTC](https://discourse.paraview.org/t/cmake-error-with-add-subdirectory-in-plugin/12717/3 "2023-08-21T01:37:17Z")
> [@ben.boeckel](#):
>
> \_vtk\_module\_apply\_properties
The reason I am not using find\_package for BLOSC and SZ is so that we can take directly what is in the GenericIO git repo and put it directly in ParaView. Is that going to be an issue for ParaView.
That got rid of the error but I’m now seeing something else now when I try to load a file with the GenericIO plugin
> bin/paraview: symbol lookup error: /home/pascal/projects/paraview\_build/lib/paraview-5.11/plugins/GenericIOReader/GenericIOReader.so: undefined symbol: \_ZN14vtkGenIOReader11SetFileNameEPc
and it quits.
Would that be something related to CMake too?
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [August 21, 2023, 2:23am UTC](https://discourse.paraview.org/t/cmake-error-with-add-subdirectory-in-plugin/12717/4 "2023-08-21T02:23:36Z")
> [@zetwal](#):
>
> The reason I am not using find\_package for BLOSC and SZ is so that we can take directly what is in the GenericIO git repo and put it directly in ParaView. Is that going to be an issue for ParaView.
Yes. We cannot ship symbols that may conflict with other sources of these libraries. This could technically work if ParaView ships a BLOSC, SZ, and GenericIO SDKs with ParaView so everyone can agree on a single source for the relevant symbols, but since BLOSC is needed by ADIOS and ParaView builds against ADIOS, that is a dependency cycle.
Just to note, we will also need to mangle GenericIO’s symbols for that matter as well. Is there a reason we cannot just use `find_package(GenericIO)` and provide it via the superbuild (it looks like we already do, but probably a 2016 vintage snapshot)?
> [@zetwal](#):
>
> bin/paraview: symbol lookup error: /home/pascal/projects/paraview\_build/lib/paraview-5.11/plugins/GenericIOReader/GenericIOReader.so: undefined symbol: \_ZN14vtkGenIOReader11SetFileNameEPc
It looks like there’s a method that is not implemented on `vtkGenIOReader`, namely `SetFileName(char*)`. It looks like a `vtkSetGetMacro` kind of function, but if it is manual, it seems to be missing from the relevant `.cxx` file.
---
### Author:  [@zetwal](https://discourse.paraview.org/u/zetwal)
#### Post date: [August 21, 2023, 2:25pm UTC](https://discourse.paraview.org/t/cmake-error-with-add-subdirectory-in-plugin/12717/5 "2023-08-21T14:25:53Z")
> [@ben.boeckel](#):
>
> It looks like there’s a method that is not implemented on `vtkGenIOReader`, namely `SetFileName(char*)`. It looks like a `vtkSetGetMacro` kind of function, but if it is manual, it seems to be missing from the relevant `.cxx` file.
I accidentally deleted setFileName when I was doing some cleanup. Bringing that back got rid of the error.
> Yes. We cannot ship symbols that may conflict with other sources of these libraries. This could technically work if ParaView ships a BLOSC, SZ, and GenericIO SDKs with ParaView so everyone can agree on a single source for the relevant symbols, but since BLOSC is needed by ADIOS and ParaView builds against ADIOS, that is a dependency cycle.
I see. For now, I’ll just keep what I have for development and then go for the find\_package once the plugin is ready.
> Just to note, we will also need to mangle GenericIO’s symbols for that matter as well. Is there a reason we cannot just use `find_package(GenericIO)` and provide it via the superbuild (it looks like we already do, but probably a 2016 vintage snapshot)?
What I’m doing is upgrading the GenericIO plugin that I put in 2016. I’m calling it 1.1 :). So, it should have the same structure. In 2016, compression was not used that much, so I ditched the BLOSC option. Now, it’s being used and SZ is in the reader as well as an octree.