tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: haskell: use buildlink3 files?

Sorry for my late response.

On 2020-04-03 17:21, Thomas Klausner wrote:
> Hi!
> While fixing some problems with non-building hs-* packages I noted
> that I can add DEPENDS to get the dependencies installed and usable by
> the Haskell compiler.
> However, most hs-* packages provide a file.
> For Python, we decided that since the compiler is not involved, we
> want to avoid using and instead use plain DEPENDS. I
> think this also gives a parsing speedup because less files are opened.
> Do we want to decide the same for Haskell, or can buildlink be
> extended to work as intended for Haskell packages as well? (I.e., that
> hs-* packages that are not buildlinked will not be found by the
> Haskell compiler.)
> If yes, is anyone willing to work on this?

I prefer to keep using buildlink3 for Haskell packages because in theory
it's better than DEPENDS if it's working correctly. Here are reasons why
it isn't working as intended right now:

1) The compiler (GHC) builds Haskell packages as native .a (and
optionally .so as well), and pkgsrc installs them.

2) While building package A which depends on another package B,
buildlink3 creates symlinks to those libraries under BUILDLINK_DIR. And
GHC invokes ld(1) with appropriate -L and -l flags.

3) However, GHC uses @file syntax for those flags. This causes our
wrapper to not rewrite them to redirect to BUILDLINK_DIR, so those
symlinks are not actually used. The reason it uses @file is apparently
that the limit on the length of argv is unacceptably short on a certain
platform, namely Windows.

4) I tried patching GHC to avoid using @file. It mostly worked except
for one specific case: building GHC itself. The build system for GHC
uses $ORIGIN for linking .so that are used by GHC. This only works
because actual ld flags mentioning $ORIGIN are hidden in @file. They'd
be removed if they were exposed to our wrapper.

5) Patching lang/ghc* to not using $ORIGIN might sound like the best
option, but it isn't necessarily so. It's in an unfortunate situation
like openjdk and rust: It needs itself to bootstrap. If we were to
disable the use of $ORIGIN, our binary bootstrap kit would no longer be
position-independent. I mean, a bootkit built for /usr/pkgsrc will no
longer work anywhere else. And also the build system is terribly
complicated and patching it is going to be a great deal of work.

6) One might argue that we should use LD_LIBRARY_PATH instead of using
$ORIGIN. That's usually the best way to go, but in this case it's not
that simple. Haskell libraries are installed under separate directory
for each library as opposed to a uniform one such as /usr/pkg/lib. To
make matters worse, those directories contain a package hash in their
name so generating a list of LD_LIBRARY_PATH is not an easy task.

7) Patching our wrapper to not removing flags that mention $ORIGIN, and
also rewriting flags in @file, comes with its own troubles. I personally
think this isn't an unacceptable change, but others don't necessarily agree.

So the situation is rather complicated. I *really* love to fix it so
buildlink does what it's intended for, but I haven't managed to do it
yet. Suggestions are welcomed.

Home | Main Index | Thread Index | Old Index