option --enable-relocatable ignored in new-build

[martijnbastiaan]

Report: after building with --enable-relocatable I expect packages built in my cabal store (~/.cabal) to only contain relative paths. This is not the case. For example, ~/.cabal/store/ghc-8.4.3/package.db/async-2.2.1-f6fb9f5a60e7ad9ce092fee6ef572c10f40bde7d58e9da909b9bc7ccddb27749.conf mentions:

import-dirs: /home/martijn/.cabal/store/ghc-8.4.3/async-2.2.1-f6fb9f5a60e7ad9ce092fee6ef572c10f40bde7d58e9da909b9bc7ccddb27749/lib

I believe either the documentation should be more explicit about what the flag tries to achieve, or cabal should produce relative paths.

Use case: I need to ship packages bundled with a program I'm trying to package as a snap/flatpack/deb. It's not enough to simply incorporate the library files in the binary, as I explicitly need the packages themselves. Right now, I'm trying to manually rewrite the paths mentioned in ~/.cabal. If there's a better way, I'd love to hear it.

[hvr]

@martijnbastiaan

What are you packaging? Do you really need to package libraries which some GHC is going to compile things against?

Note that even if --enable-relocatable worked, you'd still have a big problem with package-data (and rewriting the pkg db data wouldn't help you there, as those paths are compiled into the artifacts)

If the target install folder is already known, and you can write to it already, you can also use --storedir to have it point inside the target-install folder; this takes care of the package-data

Also related is #4097

[martijnbastiaan]

Do you really need to package libraries which some GHC is going to compile things against?

I believe so. I'm trying to package Clash, a Haskell to HDL compiler. Clash (≈GHC+wrapper) needs the packages to be able to compile user code.

you'd still have a big problem with package-data (and rewriting the pkg db data wouldn't help you there, as those paths are compiled into the artifacts)

I feared as much. I, naively, hoped I could hack my way through it by replacing those strings in there too - as the installation directory is almost certainly shorter than the cabal store path. (Thus replacing the old string by the new installation path plus a number of NUL bytes.)

If the target install folder is already known, and you can write to it already, you can also use --storedir to have it point inside the target-install folder; this takes care of the package-data

Right, of course, thanks for that pointer. I might be able to set something up in combination with fakeroot/chroot then. I'll investigate.

[martijnbastiaan]

I don't think there is a --storedir flag. What seems to work is:

HOME=/opt/clash/version/ cabal new-build all

[hvr]

@martijnbastiaan Sorry, I was already assuming we had merged that aliasing PR which adds the --storedir= alias for --store-dir=; --store-dir is global flag which (for unknown reasons to me) does not show up in --help; you can use it like

cabal --store-dir=/tmp/store new-build

and it'll start populating /tmp/store

as for the binary-patching... that's risky and may break easily if GHC switches to a length-prefixed representation for string literals, and it might get tricky if unfoldings are involved

[martijnbastiaan]

as for the binary-patching... that's risky and may break easily if GHC switches to a length-prefixed representation for string literals, and it might get tricky if unfoldings are involved

I agree. I'm pretty optimistic about the --store-dir route, so I hopefully won't have to resort to these kinds of hacks.

[23Skidoo]

/cc @christiaanb

[hvr]

@martijnbastiaan ...did you have success w/ the --store-dir approach?

[martijnbastiaan]

Not really.. HOME turned out to be the only way I could get it working, as using --store-dir produced errors down to the line. I'll work on packaging in a few weeks time again and I'll be sure to try and reproduce the error then.

The way I solved it is still quite hacky, but at least it works for now..

*edit: correct link