[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