relocatable packages: GHC_PACKAGE_PATH and package.conf

Hi all, I'm trying to build a relocatable package using cabal, and running into some difficulties. I've created / used the following script to attempt to create a relocatable package: https://github.com/gfxmonk/0compile-cabal-build/blob/2cf4a08b146333d9292f6f8... When this is done I have something that looks like it should work, and has an inline package.conf. But when I run the following: ----------------------------------------------- $ export GHC_PACKAGE_PATH="/home/tim/dev/haskell/third-party/haskell-ansi-terminal/haskell-ansi-terminal-linux-x86_64/package.conf:" $ ghc-pkg check There are problems in package ansi-terminal-0.5.5: import-dirs: ${pkgroot}/lib is a relative path library-dirs: ${pkgroot}/lib is a relative path file System/Console/ANSI.hi is missing file System/Console/ANSI/Unix.hi is missing file System/Console/ANSI/Common.hi is missing cannot find libHSansi-terminal-0.5.5.a on library path The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. ansi-terminal-0.5.5 ----------------------------------------------- So it looks like: - I need to set more environment variabes so that ghc can find the parts of the package (e.g libHSansi-terminal-0.5.5.a). Unfortunately, I don't know what "library path" refers to in the above message (I tried $LD_LIBRARY_PATH and $LIB_PATH to no avail). - 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. Can anyone suggest what I might need to fix (either in the package.conf or in my environment variables) to get this working? I've uploaded my package.conf here, apologies for the lack of formatting: https://gist.github.com/59a0d3e69751c3932579 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? If I need to add $DISTDIR/ansi-terminal-0.5.5/ghc-7.0.4/ to a library path, it would be much easier to declare that if it didn't depend on the version of GHC used. Assume that since I'm building a standalone package, there is no problem with collisions (packages for other versions of GHC or other compilers would have a different $PREFIX). I'd really like to get relocatable packages working, so any help or guidance would be appreciated. Cheers, - Tim.

On 28 May 2012 05:36, Tim Cuthbertson
- 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+
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: http://www.haskell.org/cabal/users-guide/installing-packages.html#prefix-ind... 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. Duncan

On Tue, May 29, 2012 at 12:24 AM, Duncan Coutts
On 28 May 2012 05:36, Tim Cuthbertson
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:
http://www.haskell.org/cabal/users-guide/installing-packages.html#prefix-ind...
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. Thanks, - Tim.
participants (2)
-
Duncan Coutts
-
Tim Cuthbertson