[MacPorts] #49418: vtk5: dyld: Library not loaded: /opt/local/lib/vtk-5.10/libvtksys.5.10.dylib
MacPorts
noreply at macports.org
Wed Aug 3 09:21:43 PDT 2016
#49418: vtk5: dyld: Library not loaded:
/opt/local/lib/vtk-5.10/libvtksys.5.10.dylib
-------------------------------+--------------------------------
Reporter: leonardo.pires@… | Owner: macports-tickets@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.3.4
Resolution: | Keywords: elcapitan
Port: vtk5 |
-------------------------------+--------------------------------
Comment (by seth.berrier@…):
Here's a workaround I've found that allows macports to still do all the
work (might be easier for some than building from source manually):
* Try to build with macports and let it fail
* Change to the binary working directory:
{{{
cd
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_vtk5/vtk5/work/VTK5.10.1/bin
}}}
* Use install_name_tool to change the path to the offending library for
the ProcessShader executable
{{{
sudo install_name_tool -change
/opt/local/lib/vtk-5.10/libvtksys.5.10.dylib
@executable_path/libvtksys.5.10.dylib ProcessShader
}}}
* Now, try to install again with macports (don't clean, just let it pick
up where it left off)
Near as I can tell, ProcessShader seems to just be a tool used during the
build process so you don't need to change it back afterwards. This
process of using install_name_tool to change the path to the dynamic lib
may a more robust way to address this bug but I leave that up to the
macports experts (or the VTK build process maintainers).
--
Ticket URL: <https://trac.macports.org/ticket/49418#comment:18>
MacPorts <https://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list