#12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): @carter, braindump as requested: * After reading @rwbarton's comment about a person wanting to pack up `dynlib`s for deployment in a single directory, I think I've changed my mind about installation layout. That is, I think the `install_name` of dynlibs should stay `@rpath/libname-x.y.z.dylib` as they are now. * This means that, upon installation, dynlibs should be copied to `$libdir/libname-x.y.z.dylib`, instead of the current `$libdir/libname-x.y.z/libname-x.y.z.dyblib`. * The `.hi` files should still be copied to the `$libdir/libname-x.y.z/` directory. * Perhaps the `a` static lib should also be copied to `$libdir/libname-x.y.z.ar`, for consistency with the `dynlib` dynamic lib. * Due to the use of `nub`, Cabal (in the case of `dynload deploy`) will then already make sure we only end up with a couple of `RPATH` equal to the `$libdir`s of the installed packages. * I'm not sure, but I think GHC also `nub`s the `RPATH`s (in the case of `dynload system`), this would have to be checked. * This plan doesn't involve mucking about with dynamic linking commands. So, if we go with the "put-all-the-dynlibs-in-single-directory" plan, which is what I now prefer, then we would need to do the following: * Add a `--libifacedir` setting to `Cabal`, which is, like `--libsubdir` implicitly prefixed by `$libdir`. `--libifacedir` determines where the `.hi` files go, and the default should be the same as `--libsubdir` (for all platforms) * Change the purpose of `--libsubdir` to mean the the location of the `.dylib`/`.so`/`.a` files. * For OSX only, change the default `libsubdir` to `.`, i.e. equal to `$libdir`. * Update `GHC`s Makefile, so that, on OS X, `make install` puts the `.dylib`/`.so`/`.a` in `$libdir`. Things that still need figuring out: * Do the above changes mean changes in the package database format? if so, what? * Do we need to update `stack` to use the new `--libifacedir` as well? or this it simply take over the default Cabal settings? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12479#comment:37 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler