Dynamic libraries by default and GHC 7.8
Herbert Valerio Riedel
hvr at gnu.org
Wed Nov 28 22:53:21 CET 2012
Ian Lynagh <ian at well-typed.com> writes:
> On Wed, Nov 28, 2012 at 12:34:03PM +0100, Herbert Valerio Riedel wrote:
>> Ian Lynagh <ian at 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
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.
More information about the Glasgow-haskell-users