search

conda-forge / vtk-feedstock

A conda-smithy repository for vtk.
BSD 3-Clause "New" or "Revised" License
13 stars 64 forks source link

vtk-7.0.0 hard codes system library paths in it's CMAKE config #8

Closed gdevenyi closed 7 years ago

gdevenyi commented 8 years ago

I've been running into this error trying to build against vtk:

No rule to make target `/usr/lib64/librt.so', needed by `travel_depth/TravelDepthMain'.  Stop.

I thoroughly examined the very simple VTK cmake I'm using, and I've come down to it being included somewhere else:

Grepping through the cmake files included with vtk-7.0.0:

> grep -r librt
Modules/vtkhdf5.cmake:set(vtkhdf5_LIBRARIES "/opt/quarantine/anaconda/4.1.1/build/lib/libhdf5.so;/usr/lib64/librt.so;/opt/quarantine/anaconda/4.1.1/build/lib/libz.so;/usr/lib64/libdl.so;/usr/lib64/libm.so;/opt/quarantine/anaconda/4.1.1/build/lib/libhdf5_hl.so;/opt/quarantine/anaconda/4.1.1/build/lib/libhdf5.so;/usr/lib64/librt.so;/opt/quarantine/anaconda/4.1.1/build/lib/libz.so;/usr/lib64/libdl.so;/usr/lib64/libm.so")
VTKTargets.cmake:  INTERFACE_LINK_LIBRARIES "/opt/quarantine/anaconda/4.1.1/build/lib/libhdf5.so;/usr/lib64/librt.so;/opt/quarantine/anaconda/4.1.1/build/lib/libz.so;/usr/lib64/libdl.so;/usr/lib64/libm.so;/opt/quarantine/anaconda/4.1.1/build/lib/libhdf5_hl.so;/opt/quarantine/anaconda/4.1.1/build/lib/libhdf5.so;/usr/lib64/librt.so;/opt/quarantine/anaconda/4.1.1/build/lib/libz.so;/usr/lib64/libdl.so;/usr/lib64/libm.so;m"

It looks like somehow the conda build system's library paths got embedded as target link libraries for CMAKE, so when I try and use it, it also targets those. I don't have my libraries at that location.

Korijn commented 8 years ago

Not sure about this; @jakirkham?

gdevenyi commented 8 years ago

Confirmed that if I build my own VTK-7.0 from scratch I don't have this issue.

patricksnape commented 8 years ago

Grim - looks like the cmake file is hardcoding the paths to all 'linkable' libraries and this includes system libraries such as librt that exist in /usr/lib64 on CentOS but in other places on Debian for example. I don't see why these libraries couldn't just be relative link requirements? Can you try rebuilding but changing /usr/lib64/librt.so to rt to see if CMake will just resolve the link requirements itself? If it does, then we can just sed those out in our build (I think).

Korijn commented 8 years ago

Should we file an issue with VTK maybe? Or is there already a CMAKE option to use relative paths perhaps?

patricksnape commented 8 years ago

Maybe try using CMAKE_SKIP_RPATH?

dfroger commented 7 years ago

I had a similar problem with ITK some times ago (but didn't found the solution...)

grlee77 commented 7 years ago

Can you try rebuilding but changing /usr/lib64/librt.so to rt to see if CMake will just resolve the link requirements itself?

I encountered this problem for ITK rather than VTK, but can confirm that manually editing the file to makes these changes as suggested above allowed me to build a third party project successfully. I have raised a related issue in the ITK feedstock here: https://github.com/conda-forge/itk-feedstock/issues/7

For VTK, there appear to be two files with hardcoded paths that should be removed:

Korijn commented 7 years ago

Closing this unless someone issues a plan of approach to resolve this.

ihnorton commented 5 years ago

Analysis/suggested fix in https://github.com/conda-forge/libitk-feedstock/issues/7 [edit: fixed link] PR to fix in ITK: https://github.com/InsightSoftwareConsortium/ITK/pull/343 (similar fix could be done in VTK, or arguably upstream in CMake I guess).

grlee77 commented 5 years ago

I think @ihnorton meant to link here: https://github.com/conda-forge/libitk-feedstock/issues/7

ManifoldFR commented 4 years ago

This also affects libXext.so. On my Ubuntu 19.10 the CMake build links to /usr/lib64/libXext.so which does not exist. I circumvented it with a symlink