Ian Lynagh <i...@well-typed.com> writes: > On Wed, Nov 28, 2012 at 12:34:03PM +0100, Herbert Valerio Riedel wrote: >> Ian Lynagh <i...@well-typed.com> writes: >> >> [...] >> >> > There are also some policy questions we need to answer about how Cabal >> > will work with a GHC that uses dynamic libraries by default. >> >> btw, how is it planned to have .so libraries interact with the >> soon-to-be-released cabal-install sandbox feature? > > I don't think anything special needs to be done. The RPATHs will still > point to the right DLL if it's in a sandbox. > > Please let me know if there's a problem that I'm missing, though!
I'm not sure yet if there's a problem, but doesn't using RPATH cause the cabal sandbox path getting hardcoded into the compiled binaries? I'm just wondering if such a sandboxed build would be deployable/redistributable then. For instance, IIRC, autotools/libtools based packages use wrapper-scripts to point the dynamic linker to the build-local (i.e. not installed yet) shared objects via env-vars and (used to) set the RPATH to the target install path where the shared objects will be found if the package is actually installed. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
