relocatable packages: GHC_PACKAGE_PATH and package.conf

Tim Cuthbertson tim at
Tue May 29 05:14:07 CEST 2012

On Tue, May 29, 2012 at 12:24 AM, Duncan Coutts
<duncan.coutts at> wrote:
> On 28 May 2012 05:36, Tim Cuthbertson <tim at> wrote:
>>  - ghc doesn't seem to support ${pkgroot} prefixes. I thought it did,
>> but I'm new to this so I may be misunderstanding where they can be
>> used.
> I thought it did too since I think I wrote the code for it. I don't
> recall exactly what version it got into, it may well have been only
> 7.2+

Ahh, right you are - I must have looked at the "reported" version
instead of "milestone" in the bug:

$ git name-rev --tags 40b6bd47cf00f025426746bbd7abdd0eda2a3afd
40b6bd47cf00f025426746bbd7abdd0eda2a3afd tags/ghc-7.2.1-release~397

I'll have to compile it myself, but that's much better than it simply
not working ;)

>> Additionally, the paths that come out of cabal build have the compiler
>> name and version hard coded, e.g lib/packagename/ghc-7.0.4/*. Is there
>> any way to configure how this path is constructed to get rid of the
>> ghd-7.0.4 part?
> By default, yes, cabal produces absolute packages. It does have
> support for relocatable packages on some compiler/platform combos:
> sadly ghc on unix is not one of them because we do not have a reliable
> way to find the program location (needed to find data files etc).
> Actually more specifically it's not easy and nobody has implemented
> it, rather than it being impossible.
> So at the moment you could work around it in specific cases by hacking
> the package registration info before registering. Do something like:
> cabal copy --destdir=...
> cabal register --gen-pkg-config=blah.pkg
> sed -i =e '...' blah.pkg
> Obviously your app/library had better not use the Cabal-provided
> functions for finding data files at runtime since that'll get
> confused.
> If you want a proper solution you'll have to help us implement the
> Cabal prefix independence feature for the ghc/unix combo.

Cheers, yeah I'd like to get this working on a simple library first -
so I'm not bothered about the inability to find data files.

But once that's working, I'm sufficiently convinced that this needs to
work to help / implement it myself. When you say it's possible but
nobody's happened to implement it yet, do you have any more specific
hints to give? This would be my first time hacking on GHC, so
hopefully it's not too massive a task.

 - Tim.

More information about the Glasgow-haskell-users mailing list