Dynamic libraries by default and GHC 7.8

[Herbert Valerio Riedel]

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
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.