Christiaan Baaij | 13 Nov 14:10 2012
Picon

Wrong install-name path for shared/dynamic C-library on OS X

Dear List,

The context of my problem is the following:
- ghc-HEAD uses shared-library _only_ on OS X
- A cabalized package that builds a shared/dynamic C-library (GLFW-b)

And my problem is:
A dynamically linked Haskell library gets the wrong install-name for a C-library:

otool -L ~/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111/libHSGLFW-b-0.1.0.5-ghc7.7.20121111.dylib:
/Users/baaijcpr/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111/libHSGLFW-b-0.1.0.5-ghc7.7.20121111.dylib:
....
   build/libglfw.dylib (compatibility version 1.0.0, current version 1.0.0)
....

All the other paths reported by 'otool -L' are absolute, while the C-library (libglfw.dylib) that was part
of the Cabalized package is relative.
The problem presents itself when I now want to use the GLFW-b package:

Loading package GLFW-b-0.1.0.5 ... can't load .so/.DLL for:
/Users/baaijcpr/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111/libHSGLFW-b-0.1.0.5-ghc7.7.20121111.dylib
(dlopen(/Users/baaijcpr/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111/libHSGLFW-b-0.1.0.5-ghc7.7.20121111.dylib,
9): Library not loaded: build/libglfw.dylib
  Referenced from: /Users/baaijcpr/.cabal/lib/GLFW-b-0.1.0.5/ghc-7.7.20121111/libHSGLFW-b-0.1.0.5-ghc7.7.20121111.dylib
  Reason: image not found)

I can update the install-name to the correct path using:
install_name_tool -change build/libglfw.dylib  <at> loader_path/libglfw.dylib libHSGLFW-b-0.1.0.5-ghc7.7.20121111.dylib

So my question are:
(Continue reading)


Gmane