Bug 2083958

Thanks for reporting

I think this is because ghc9.2 is built with the new ghc Hadrian buildsystem,
and I had to bundle libffi instead of using the system due to some build config issues.

But we just fixed this for the coming 9.4 release.

Let me see if I can backport the fix to 9.2 as well.

Though it is possible the change of directory layout might still affect you.

It might help me if you are able to share your exact build steps
so that I can test it locally too.

Thanks!

Btw, disregard my second complain about rts library path, i did not actually use it correctly.

Also if you want you can try the new ghc9.4 alpha1 package.
I just pushed it for updates-testing, though you can install directly from koji:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1964732

Eg I used koji-tool like this:

$ koji-tool install ghc9.4 -x '*prof' -x '*doc' -x compiler-default

But it kind of sounds like your problem is with the newer directory structure
not the bundling of the libffi library. If so I am less sure how to fix that.

(In reply to Jens Petersen from comment #3)
> It might help me if you are able to share your exact build steps
> so that I can test it locally too.

Not sure that it would be simple to reproduce the build steps as it requires installing Nginx.

The issue arises when I build nginx-haskell-module (https://github.com/lyokha/nginx-haskell-module). This module does not link against any Haskell library at compile time (it links them in run-time via custom Haskell handlers - i.e. plain FFI libraries - using dlopen()), however it #include <HsFFI.h> to access GHC type declarations.

Nginx provides a simple mechanism to build Makefiles via configure script by writing file named *config* associated with the Nginx module. After putting there line

> ngx_module_incs="$(ghc --print-libdir)/include"

the configure scripts creates a C flag like -I/path/to/GHC/libdir/include when running

> ./configure --add-module=$HOME/devel/nginx-haskell-module

And obviously, make breaks with error message

> In file included from /home/lyokha/devel/nginx-haskell-module/src/ngx_http_haskell_module.c:17:
> /home/lyokha/devel/nginx-haskell-module/src/ngx_http_haskell_module.h:25:10: fatal error: HsFFI.h: No such file or directory
>    25 | #include <HsFFI.h>
>       |          ^~~~~~~~~
> compilation terminated.

I also built docker images for Fedora 35 and ghc8.10, ghc9.0 and ghc9.2 (from https://raw.githubusercontent.com/lyokha/nginx-haskell-module/master/docker/Dockerfile), but for ghc9.2 I needed to put line

> ln -s /usr/lib64/ghc-9.2.2/include /usr/lib64/ghc-9.2.2/lib

before the ./configure to embed the /include directory into the directory that $(ghc --print-libdir) prints.

OTOH, I also made github CI action to build the module with GHC 9.2 as well (https://raw.githubusercontent.com/lyokha/nginx-haskell-module/master/.github/workflows/ci.yml), however it builds GHC installed by ghcup from https://github.com/haskell/actions on Ubuntu, as I see in build logs

> Installing ghc version 9.2.2
>   /opt/hostedtoolcache/ghcup/0.1.17.6/x64/ghcup set ghc 9.2.2
>   [ Info  ] GHC 9.2.2 successfully set as default version
>   
>   
>   Found ghc 9.2.2 in cache at path /home/runner/.ghcup/ghc/9.2.2/bin. Setup successful.

 And it worked just fine (i.e. it seems that it installed GHC directories in the *expected* way).

I filed the bug at GHC's: https://gitlab.haskell.org/ghc/ghc/-/issues/21609

Thanks again for reporting this

(In reply to Alexey Radkov from comment #7)
> The issue arises when I build nginx-haskell-module
> (https://github.com/lyokha/nginx-haskell-module). This module does not link
> against any Haskell library at compile time (it links them in run-time via
> custom Haskell handlers - i.e. plain FFI libraries - using dlopen()),
> however it #include <HsFFI.h> to access GHC type declarations.

Ah I see, cool - that is interesting!
I haven't really seen such usage much before.

> Nginx provides a simple mechanism to build Makefiles via configure script by
> writing file named *config* associated with the Nginx module. After putting
> there line
> 
> > ngx_module_incs="$(ghc --print-libdir)/include"

Does it help if you append /../include instead of /include ?

> I also built docker images for Fedora 35 and ghc8.10, ghc9.0 and ghc9.2
> (from
> https://raw.githubusercontent.com/lyokha/nginx-haskell-module/master/docker/
> Dockerfile), but for ghc9.2 I needed to put line
> 
> > ln -s /usr/lib64/ghc-9.2.2/include /usr/lib64/ghc-9.2.2/lib
> 
> before the ./configure to embed the /include directory into the directory
> that $(ghc --print-libdir) prints.

I guess I can try to add such a symlink to the package for back-compat.
Thanks for filing the upstream issue.

> OTOH, I also made github CI action to build the module with GHC 9.2 as well
> (https://raw.githubusercontent.com/lyokha/nginx-haskell-module/master/.
> github/workflows/ci.yml), however it builds GHC installed by ghcup from
> https://github.com/haskell/actions on Ubuntu, as I see in build logs
> 
> > Installing ghc version 9.2.2
> >   /opt/hostedtoolcache/ghcup/0.1.17.6/x64/ghcup set ghc 9.2.2
> >   [ Info  ] GHC 9.2.2 successfully set as default version
> >   
> >   Found ghc 9.2.2 in cache at path /home/runner/.ghcup/ghc/9.2.2/bin. Setup successful.
> 
>  And it worked just fine (i.e. it seems that it installed GHC directories in
> the *expected* way).

I just checked with the upstream ghcup maintainer and apparently the ghc 9.2.2 bindists
it provides are only built with Hadrian for Alpine and MacOS. So that explains the discrepancy.

I am hoping this may get fixed for 9.2.3, but that may take some time.

I will try to add a symlink later when I have time to rebuild ghc9.2 (and ghc9.4).
Sorry for the inconvenience, though I would like to ship 9.2+ built with the newer Hadrian system.

> Does it help if you append /../include instead of /include ?

Yes, it helps, but it does not look reliable as the path may change in other releases of GHC.

> I guess I can try to add such a symlink to the package for back-compat.
> Thanks for filing the upstream issue.

The issue was already assigned and bound to 9.4.1 milestone, I think that the best option would be waiting until its resolution.

> Sorry for the inconvenience, though I would like to ship 9.2+ built with the newer Hadrian system.

Not a problem at all, I will customize paths in the config until the issue gets fixed in the upstream.

Thanks! I really appreciate your work in bringing GHC to Fedora!

Thanks, Alexey

I am pushing ghc9.2-9.2.2-9.fc37 to Rawhide,
which among other things adds an include/ symlink.

Thank you!

> I am pushing ghc9.2-9.2.2-9.fc37 to Rawhide

Unfortunately the build is failing on s390x
(due to libffi changes I made I think)
so it may have to wait for 9.2.3.

FEDORA-2022-09a95704d9 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-09a95704d9

FEDORA-2022-09a95704d9 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-09a95704d9`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-09a95704d9

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Looks that it had better solution (from my side): see https://gitlab.haskell.org/ghc/ghc/-/issues/21609#note_435800.

Command

$ ghc --print-libdir

has a better variant for finding include files:

$ ghc-pkg field rts include-dirs  --simple-output

This prints identical set of include files containing HsFFI.h and ghcversion.h as well. So I switched to this command and tested this for GHC versions 8.0 through 9.4, and this worked well. So, symbolic links are probably not needed as ghc-pkg is able to retrieve necessary information without them.

Great, thanks Alexey

Then I guess I can drop the symlink from ghc9.2

Yes, the new command works well for all versions of GHC. Thank you very much!

FEDORA-2022-09a95704d9 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.