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 @loader_path/libglfw.dylib libHSGLFW-b-0.1.0.5-ghc7.7.20121111.dylib So my question are: - Where does the original install_name path (build/libglfw.dyli) come from? - What should be specified in the .cabal and/or Setup.hs file so that the haskell library is installed using the _correct_ relative path? Cheers, Christiaan