# X11:X11 target not found when uprgrading from vtk 8 to 9 on Rocky9 linux

**URL:** https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295
**Category:** Support
**Created:** [February 22, 2025, 4:58am UTC](https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295 "2025-02-22T04:58:15Z")
**Posts on this page:** 14
**Page:** 1

<div class="post-metadata">

### Author: ![x7w53](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/x/e8c25b/32.png) [@x7w53](https://discourse.vtk.org/u/x7w53)
#### Post date: [February 22, 2025, 4:58am UTC](https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295/1 "2025-02-22T04:58:15Z")

</div>

Our top level cmake command succeeded on Rocky9 linux when using a manual build of vtk 8.2. But now when trying to switch to the native version of vtk 9.1.0 as installed on Rocky9 linux from the epel repo, anything in cmake that tries to link in vtk libraries via target\_link\_libraries(my\_binary ${VTK\_LIBRARIES}) fails the cmake command with an error “my\_binary links to target “X11::X11” but the target was not found”. I’ve seen various postings saying this could be from missing X11 libraries, but I don’t see any missing packages. I believe I’m using the same Rocky9 image where the cmake command succeeds with vtk 8.2. It also looks to me like cmake reports the X11 variables to be the same as when the cmake command succeeds using vtk 8.2:

X11\_LIBRARIES=/usr/lib64/libX11.so;/usr/lib64/libXmu.so;/usr/lib64/libXt.so  
X11\_INCLUDE\_DIR=/usr/include

… installed packages with x11 or libx in their name …

libX11-common.noarch libX11-devel.x86\_64 libX11-xcb.i686 libX11-xcb.x86\_64 libX11.i686 libX11.x86\_64 libXau-devel.x86\_64 libXau.i686 libXau.x86\_64 libXaw.x86\_64 libXcomposite.x86\_64 libXcursor-devel.x86\_64 libXcursor.i686 libXcursor.x86\_64 libXdamage.x86\_64 libXext-devel.x86\_64 libXext.x86\_64 libXfixes-devel.x86\_64 libXfixes.i686 libXfixes.x86\_64 libXft.x86\_64 libXi-devel.x86\_64 libXi.x86\_64 libXinerama.x86\_64 libXmu-devel.x86\_64 libXmu.x86\_64 libXpm.x86\_64 libXrandr.x86\_64 libXrender-devel.x86\_64 libXrender.i686 libXrender.x86\_64 libXt-devel.x86\_64 libXt.x86\_64 libXtst.x86\_64 libXv.x86\_64 libXxf86vm.x86\_64 libxcb-devel.x86\_64 libxcb.i686 libxcb.x86\_64 libxcrypt-compat.x86\_64 libxcrypt-devel.x86\_64 libxcrypt.x86\_64 libxkbcommon-devel.x86\_64 libxkbcommon-x11.x86\_64 libxkbcommon.x86\_64 libxml2-devel.x86\_64 libxml2.x86\_64 libxshmfence.x86\_64 libxslt.x86\_64 qt5-qtx11extras-devel.x86\_64 qt5-qtx11extras.x86\_64 xorg-x11-fonts-Type1.noarch xorg-x11-fonts-misc.noarch xorg-x11-proto-devel.noarch

Then for the vtk variables, I see what is listed below for vtk 9.1.0. Please advise.

VTK\_DIR=/lib64/cmake/vtk  
VTK\_LIBRARIES=VTK::WrappingTools;VTK::WebPython;VTK::WebCore;VTK::Python;VTK::vtksys;VTK::WebGLExporter;VTK::ViewsQt;VTK::ViewsInfovis;VTK::CommonColor;VTK::Java;VTK::ViewsContext2D;VTK::loguru;VTK::TestingRendering;VTK::TestingCore;VTK::RenderingTk;VTK::RenderingQt;VTK::PythonContext2D;VTK::RenderingVolumeOpenGL2;VTK::glew;VTK::opengl;VTK::PythonInterpreter;VTK::RenderingLabel;VTK::octree;VTK::RenderingLOD;VTK::RenderingImage;VTK::RenderingContextOpenGL2;VTK::IOVeraOut;VTK::hdf5;VTK::IOTecplotTable;VTK::IOSegY;VTK::IOParallelXML;VTK::IOPLY;VTK::IOOggTheora;VTK::theora;VTK::ogg;VTK::IONetCDF;VTK::netcdf;VTK::IOMySQL;VTK::TestingIOSQL;VTK::IOMotionFX;VTK::pegtl;VTK::IOParallel;VTK::jsoncpp;VTK::RenderingParallel;VTK::IOMINC;VTK::IOLSDyna;VTK::IOInfovis;VTK::libxml2;VTK::zlib;VTK::IOImport;VTK::IOIOSS;VTK::ioss;VTK::exodusII;VTK::cgns;VTK::IOHDF;VTK::IOVideo;VTK::IOMovie;VTK::IOExportPDF;VTK::libharu;VTK::IOExportGL2PS;VTK::RenderingGL2PSOpenGL2;VTK::gl2ps;VTK::png;VTK::IOExport;VTK::RenderingVtkJS;VTK::IOGeometry;VTK::RenderingSceneGraph;VTK::IOExodus;VTK::IOEnSight;VTK::IOCityGML;VTK::pugixml;VTK::IOChemistry;VTK::IOCONVERGECFD;VTK::IOCGNSReader;VTK::IOAsynchronous;VTK::IOAMR;VTK::InteractionImage;VTK::InfovisBoostGraphAlgorithms;VTK::InfovisBoost;VTK::ImagingStencil;VTK::ImagingStatistics;VTK::ImagingOpenGL2;VTK::ImagingMorphological;VTK::ImagingMath;VTK::ImagingFourier;VTK::GUISupportQtSQL;VTK::IOSQL;VTK::sqlite;VTK::GUISupportQtQuick;VTK::GUISupportQt;VTK::GeovisGDAL;VTK::IOGDAL;VTK::GeovisCore;VTK::libproj;VTK::InfovisLayout;VTK::ViewsCore;VTK::InteractionWidgets;VTK::RenderingVolume;VTK::RenderingAnnotation;VTK::ImagingHybrid;VTK::ImagingColor;VTK::InteractionStyle;VTK::FiltersTopology;VTK::FiltersSelection;VTK::FiltersSMP;VTK::FiltersPython;VTK::FiltersProgrammable;VTK::FiltersPoints;VTK::FiltersVerdict;VTK::verdict;VTK::FiltersParallelImaging;VTK::FiltersImaging;VTK::ImagingGeneral;VTK::FiltersHyperTree;VTK::FiltersGeneric;VTK::TestingGenericBridge;VTK::FiltersFlowPaths;VTK::eigen;VTK::FiltersAMR;VTK::FiltersParallel;VTK::IOParallelExodus;VTK::FiltersTexture;VTK::FiltersModeling;VTK::FiltersHybrid;VTK::DomainsMicroscopy;VTK::DomainsChemistryOpenGL2;VTK::RenderingOpenGL2;VTK::RenderingUI;VTK::DomainsChemistry;VTK::CommonPython;VTK::WrappingPythonCore;VTK::CommonArchive;VTK::ChartsCore;VTK::InfovisCore;VTK::FiltersExtraction;VTK::ParallelDIY;VTK::diy2;VTK::IOXML;VTK::IOXMLParser;VTK::expat;VTK::ParallelCore;VTK::IOLegacy;VTK::IOCore;VTK::doubleconversion;VTK::lz4;VTK::lzma;VTK::utf8;VTK::FiltersStatistics;VTK::ImagingSources;VTK::IOImage;VTK::DICOMParser;VTK::jpeg;VTK::metaio;VTK::tiff;VTK::RenderingContext2D;VTK::RenderingFreeType;VTK::freetype;VTK::kwiml;VTK::RenderingCore;VTK::FiltersSources;VTK::ImagingCore;VTK::FiltersGeometry;VTK::FiltersGeneral;VTK::fmt;VTK::CommonComputationalGeometry;VTK::FiltersCore;VTK::CommonExecutionModel;VTK::CommonDataModel;VTK::CommonSystem;VTK::CommonMisc;VTK::exprtk;VTK::CommonTransforms;VTK::CommonMath;VTK::kissfft;VTK::CommonCore;VTK::cli11

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [March 3, 2025, 11:11pm UTC](https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295/2 "2025-03-03T23:11:10Z")

</div>

I believe that 9.1.0 had issues with the no-component variant of `find_package(VTK)`. Can you try adding `COMPONENTS …` to your `find_package(VTK)` call that list the components you need?

---

<div class="post-metadata">

### Author: ![x7w53](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/x/e8c25b/32.png) [@x7w53](https://discourse.vtk.org/u/x7w53)
#### Post date: [March 4, 2025, 8:19am UTC](https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295/3 "2025-03-04T08:19:22Z")

</div>

Thank you Ben - that does work and has allowed me to successfully run a cmake command by specifying some components like CommonCore CommonTransforms IOXML in the list following the COMPONENTS keyword. But since cmake 8.2 did not require specifying components, I don’t know exactly what the component list should be for 9.1.0. As I fault thru our build I come across undefined references to, e.g., vtkRGBATransferFunction, which I do not see directly listed in the Rocky9 system file, /lib64/cmake/vtk/vtk-config.cmake. I have not found any \*.modules file to maybe help with mapping that function back to a component. The /lib64/cmake/vtk/vtk-config.cmake does however list the following components,

WrappingTools;WebPython;WebCore;Python;vtksys;WebGLExporter;ViewsQt;ViewsInfovis;CommonColor;Java;ViewsContext2D;loguru;TestingRendering;TestingCore;RenderingTk;RenderingQt;PythonContext2D;RenderingVolumeOpenGL2;glew;opengl;PythonInterpreter;RenderingLabel;octree;RenderingLOD;RenderingImage;RenderingContextOpenGL2;IOVeraOut;hdf5;IOTecplotTable;IOSegY;IOParallelXML;IOPLY;IOOggTheora;theora;ogg;IONetCDF;netcdf;IOMySQL;TestingIOSQL;IOMotionFX;pegtl;IOParallel;jsoncpp;RenderingParallel;IOMINC;IOLSDyna;IOInfovis;libxml2;zlib;IOImport;IOIOSS;ioss;exodusII;cgns;IOHDF;IOVideo;IOMovie;IOExportPDF;libharu;IOExportGL2PS;RenderingGL2PSOpenGL2;gl2ps;png;IOExport;RenderingVtkJS;IOGeometry;RenderingSceneGraph;IOExodus;IOEnSight;IOCityGML;pugixml;IOChemistry;IOCONVERGECFD;IOCGNSReader;IOAsynchronous;IOAMR;InteractionImage;InfovisBoostGraphAlgorithms;InfovisBoost;ImagingStencil;ImagingStatistics;ImagingOpenGL2;ImagingMorphological;ImagingMath;ImagingFourier;GUISupportQtSQL;IOSQL;sqlite;GUISupportQtQuick;GUISupportQt;GeovisGDAL;IOGDAL;GeovisCore;libproj;InfovisLayout;ViewsCore;InteractionWidgets;RenderingVolume;RenderingAnnotation;ImagingHybrid;ImagingColor;InteractionStyle;FiltersTopology;FiltersSelection;FiltersSMP;FiltersPython;FiltersProgrammable;FiltersPoints;FiltersVerdict;verdict;FiltersParallelImaging;FiltersImaging;ImagingGeneral;FiltersHyperTree;FiltersGeneric;TestingGenericBridge;FiltersFlowPaths;eigen;FiltersAMR;FiltersParallel;IOParallelExodus;FiltersTexture;FiltersModeling;FiltersHybrid;DomainsMicroscopy;DomainsChemistryOpenGL2;RenderingOpenGL2;RenderingUI;DomainsChemistry;CommonPython;WrappingPythonCore;CommonArchive;ChartsCore;InfovisCore;FiltersExtraction;ParallelDIY;diy2;IOXML;IOXMLParser;expat;ParallelCore;IOLegacy;IOCore;doubleconversion;lz4;lzma;utf8;FiltersStatistics;ImagingSources;IOImage;DICOMParser;jpeg;metaio;tiff;RenderingContext2D;RenderingFreeType;freetype;kwiml;RenderingCore;FiltersSources;ImagingCore;FiltersGeometry;FiltersGeneral;fmt;CommonComputationalGeometry;FiltersCore;CommonExecutionModel;CommonDataModel;CommonSystem;CommonMisc;exprtk;CommonTransforms;CommonMath;kissfft;CommonCore;cli11

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [March 4, 2025, 8:36am UTC](https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295/4 "2025-03-04T08:36:49Z")

</div>

Using a checkout of 9.1.0 and [`WhatModulesVTK.py`](https://gitlab.kitware.com/vtk/vtk/-/blob/master/Utilities/Maintenance/WhatModulesVTK.py) may help here.

---

<div class="post-metadata">

### Author: ![x7w53](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/x/e8c25b/32.png) [@x7w53](https://discourse.vtk.org/u/x7w53)
#### Post date: [March 17, 2025, 12:26am UTC](https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295/5 "2025-03-17T00:26:30Z")

</div>

Thanks - i was able to use the python script(s) from the 9.1.0 source code distribution as you suggested and get a list of Components to start with. I then added some other components, and now almost everything is compiling. The issue I currently have is that when I add in the component RenderingOpenGL2 the references to X11 once again break when running the top level cmake command, and cmake fails. I read that setting VTK\_MODULE\_ENABLE\_VTK\_RenderingContextOpenGL2=ON is necessary for Open GL2 (and so set that), but that makes no difference w.r.t the addition of RenderingOpenGL2 causing cmake to fail finding the X11 component. Is there an order dependency in how the components are listed? Right now I am trying to list them in lexicogrpahic order, i.e.,

find\_package(VTK HINTS ${VTK\_DIR} COMPONENTS CommonCore CommonDataModel CommonMath CommonSystem CommonTransforms FiltersCore FiltersExtraction FiltersGeneral FiltersGeometry FiltersHybrid FiltersModeling FiltersPoints FiltersSources IOExport IOGeometry IOImage IOLegacy IOXML ImagingCore ImagingGeneral ImagingMath ImagingMorphological ImagingStencil RenderingCore RenderingFreeType RenderingLOD RenderingOpenGL2 RenderingVolume)

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [March 17, 2025, 12:39pm UTC](https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295/6 "2025-03-17T12:39:07Z")

</div>

> [@x7w53](#):
>
> Is there an order dependency in how the components are listed? Right now I am trying to list them in lexicogrpahic order, i.e.,

No, there shouldn’t be. There’s a block of logic leading up to the `find_package(X11)` inside of VTK’s package. I’d trace that logic. I know there were bugs fixed since 9.1 that may affect this. Does a `master` build work as expected?

---

<div class="post-metadata">

### Author: ![x7w53](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/x/e8c25b/32.png) [@x7w53](https://discourse.vtk.org/u/x7w53)
#### Post date: [March 19, 2025, 11:54am UTC](https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295/7 "2025-03-19T11:54:50Z")

</div>

I’m trying to use the native vtk install on Rocky9 Linux. Not sure I understand why **/lib64/cmake/vtk/VTK-vtk-module-find-packages.cmake** apparently defines **find\_package(X11)** twice - see listing below. In between there is some logic relating to **RenderingOpenGL2** which is the module I’m trying to add that causes the X11 not found error to re-appear.

I thought I saw a posting that said it is preferable now to not use VTK\_LIBRARIES when linking and instead, spell out the individual VTK components to link against for each application. Just wondering if that more explicit/specific instruction about what to link against might remedy this issue.

```auto
find_package(X11
  
  
  
  ${_vtk_module_find_package_quiet}
  ${_vtk_module_find_package_required}
  COMPONENTS          
  OPTIONAL_COMPONENTS )
if (NOT X11_FOUND AND _vtk_module_find_package_fail_if_not_found)
  if (NOT ${CMAKE_FIND_PACKAGE_NAME}_FIND_QUIETLY)
    message(STATUS
      "Could not find the ${CMAKE_FIND_PACKAGE_NAME} package due to a "
      "missing dependency: X11")
  endif ()
  set("${CMAKE_FIND_PACKAGE_NAME}_RenderingOpenGL2_FOUND" 0)
  list(APPEND "${CMAKE_FIND_PACKAGE_NAME}_RenderingOpenGL2_NOT_FOUND_MESSAGE"
    "Failed to find the X11 package.")
endif ()
endif ()

unset(_vtk_module_find_package_fail_if_not_found)
unset(_vtk_module_find_package_enabled)
unset(_vtk_module_find_package_required)

set(_vtk_module_find_package_enabled OFF)
set(_vtk_module_find_package_is_required OFF)
set(_vtk_module_find_package_fail_if_not_found OFF)
if (_vtk_module_find_package_components)
if ("RenderingUI" IN_LIST _vtk_module_find_package_components)
  set(_vtk_module_find_package_enabled ON)
  if ("RenderingUI" IN_LIST _vtk_module_find_package_components_required)
    set(_vtk_module_find_package_is_required "${${CMAKE_FIND_PACKAGE_NAME}_FIND_REQUIRED}")
    set(_vtk_module_find_package_fail_if_not_found ON)
  endif ()
endif ()
else ()
set(_vtk_module_find_package_enabled ON)
set(_vtk_module_find_package_is_required "${${CMAKE_FIND_PACKAGE_NAME}_FIND_REQUIRED}")
set(_vtk_module_find_package_fail_if_not_found ON)
endif ()

if (_vtk_module_find_package_enabled)
set(_vtk_module_find_package_required)
if (_vtk_module_find_package_is_required)
  set(_vtk_module_find_package_required REQUIRED)
endif ()

find_package(X11
  
  
  
  ${_vtk_module_find_package_quiet}
  ${_vtk_module_find_package_required}
  COMPONENTS          
  OPTIONAL_COMPONENTS )
if (NOT X11_FOUND AND _vtk_module_find_package_fail_if_not_found)
  if (NOT ${CMAKE_FIND_PACKAGE_NAME}_FIND_QUIETLY)
    message(STATUS
      "Could not find the ${CMAKE_FIND_PACKAGE_NAME} package due to a "
      "missing dependency: X11")
  endif ()
  set("${CMAKE_FIND_PACKAGE_NAME}_RenderingUI_FOUND" 0)
  list(APPEND "${CMAKE_FIND_PACKAGE_NAME}_RenderingUI_NOT_FOUND_MESSAGE"
    "Failed to find the X11 package.")
endif ()
endif ()

```

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [March 19, 2025, 12:13pm UTC](https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295/8 "2025-03-19T12:13:23Z")

</div>

> [@x7w53](#):
>
> Not sure I understand why **/lib64/cmake/vtk/VTK-vtk-module-find-packages.cmake** apparently defines **find\_package(X11)** twice

There are multiple modules that depend on X11. If either module is requested, the package needs to be found.

> [@x7w53](#):
>
> I thought I saw a posting that said it is preferable now to not use VTK\_LIBRARIES when linking and instead, spell out the individual VTK components to link against for each application.

Yes, this is true.

> [@x7w53](#):
>
> Just wondering if that more explicit/specific instruction about what to link against might remedy this issue.

Listing the required modules in `find_package(COMPONENTS)` is more likely to remedy the situation.

---

<div class="post-metadata">

### Author: ![x7w53](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/x/e8c25b/32.png) [@x7w53](https://discourse.vtk.org/u/x7w53)
#### Post date: [March 24, 2025, 5:49am UTC](https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295/9 "2025-03-24T05:49:08Z")

</div>

I tried setting target\_link\_libraries(appname VTK::component VTK::component …) as needed per application instead of listing all the vtk components used across all apps in a top level find\_package VTK function. But as soon as I add either the GUISupport or RenderingOpenGL2 component into any applications target\_link\_libraries vtk component list, then the X11 include error happens. I see in the rocky9 system file VTK-targets.cmake that RenderingOpenGL2 lists X11:X11 in INTERFACE\_LINK\_LIBRARIES along with RenderingGUI. Then RenderingGUI lists X11:X11 again in its INTERFACE\_LINK\_LIBRARIES components. Eliminating those X11 references did not make any difference. As a workaround to not being able to add in the RenderingOpenGL2 component into target\_link\_libraries function for the application that needs it, I tried adding link\_directories(path) to the system path where libvtkRenderingOpenGL2.so lives. With that addition, it does look like the linker is now finding that library. However, I am not sure this mixture of using both target\_link\_libraries(appname VTK::component VTK::component …) with deliberately excluded components that are needed - along with the added link\_directories(systempath) - is going to work or be the correct way to build things. Finally, I see the rocky9 system has a file /lib64/cmake/vtk/patches /3.19/FindX11.cmake. That looks like a function to update the X11 definitions. I tried including that file to be read in the CMakeLists.txt for the application that needs the RenderingOpenGL2 component, but I still get the X11 include with RenderingOpenGL2 added into target\_link\_libraries. Not sure how to proceed at this point.

---

<div class="post-metadata">

### Author: ![x7w53](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/x/e8c25b/32.png) [@x7w53](https://discourse.vtk.org/u/x7w53)
#### Post date: [March 24, 2025, 5:51am UTC](https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295/10 "2025-03-24T05:51:45Z")

</div>

> [@x7w53](#):
>
> but I still get the X11 include with RenderingOpenGL2 added into target\_link\_libraries. Not sure how to proceed at this point.

… should have said still get the X11 include _error_ when adding RenderingOpenGL2 added into target\_link\_libraries …

---

<div class="post-metadata">

### Author: ![x7w53](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/x/e8c25b/32.png) [@x7w53](https://discourse.vtk.org/u/x7w53)
#### Post date: [March 27, 2025, 1:24am UTC](https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295/11 "2025-03-27T01:24:41Z")

</div>

I should have noticed the files installed under /lib64/cmake/vtk/patches on the rocky9 machine work as updates/additions to the /lib64/cmake/vtk/\*.cmake files. After copying them into /lib64/cmake/vtk the find X11 error is gone now when I add any OpenGL2 component to the list of vtk libraries.

```auto
/lib64/cmake/vtk/patches % find . -type f -name "*.cmake"
./99/FindHDF5.cmake
./99/FindOpenGL.cmake
./3.13/FindZLIB.cmake
./3.16/FindPostgreSQL.cmake
./3.19/FindJPEG.cmake
./3.19/FindLibArchive.cmake
./3.19/FindSQLite3.cmake
./3.19/FindX11.cmake
./3.20/FindGDAL.cmake
./3.22/FindMPI.cmake
./3.18/FindPython2.cmake
./3.18/FindPython/Support.cmake
./3.18/FindPython3.cmake

```

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [March 28, 2025, 8:24am UTC](https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295/12 "2025-03-28T08:24:43Z")

</div>

VTK should be adding these to its module path automatically. Can you see why that might be failing?

---

<div class="post-metadata">

### Author: ![x7w53](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/x/e8c25b/32.png) [@x7w53](https://discourse.vtk.org/u/x7w53)
#### Post date: [September 3, 2025, 5:45am UTC](https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295/13 "2025-09-03T05:45:53Z")

</div>

I’m not aware VTK\_DIR can be set like a PATH variable with colon separated entries to denote multiple search paths. While setting VTK\_DIR=/lib64/cmake/vtk picks up all the \*.cmake files in that directory, I don’t see anything under /lib64/cmake/vtk/patches/ is found. The AI help/search assistant in various browsers lists that people have been copying in the files from the child ./patches//\* subdirs into the parent /lib64/cmake/vtk directory.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [September 8, 2025, 12:07am UTC](https://discourse.vtk.org/t/x11-x11-target-not-found-when-uprgrading-from-vtk-8-to-9-on-rocky9-linux/15295/14 "2025-09-08T00:07:38Z")

</div>

VTK adds those paths to `CMAKE_MODULE_PATH` for the duration of `vtk-config.cmake` and then remove them again.
