GHC 8.10 bundles libffi in the most recent update. Filtering out libffi symbols appears to be missing from the build: https://koji.fedoraproject.org/koji/rpminfo?rpmID=33414148 As seen by providing libffi: ~~~ libffi.so.7()(64bit) libffi.so.7(LIBFFI_BASE_7.0)(64bit) libffi.so.7(LIBFFI_BASE_7.1)(64bit) libffi.so.7(LIBFFI_CLOSURE_7.0)(64bit) libffi.so.7(LIBFFI_COMPLEX_7.0)(64bit) libffi.so.7(LIBFFI_GO_CLOSURE_7.0)(64bit) ~~~ My expectation would be that ghc8.10 does not provide any of the libffi.so.* provides and that they are all filtered out. See: https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/#_private_libraries
(I probably need to test bug 2166028 first also to see if ghc8.10 can rebuild now yet in koji.) (In reply to Carlos O'Donell from comment #0) > Filtering out libffi symbols appears to be missing from the build: > https://koji.fedoraproject.org/koji/rpminfo?rpmID=33414148 > > As seen by providing libffi: > ~~~ > libffi.so.7()(64bit) > libffi.so.7(LIBFFI_BASE_7.0)(64bit) > libffi.so.7(LIBFFI_BASE_7.1)(64bit) > libffi.so.7(LIBFFI_CLOSURE_7.0)(64bit) > libffi.so.7(LIBFFI_COMPLEX_7.0)(64bit) > libffi.so.7(LIBFFI_GO_CLOSURE_7.0)(64bit) > ~~~ > > My expectation would be that ghc8.10 does not provide any of the libffi.so.* > provides and that they are all filtered out. > > See: > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > AutoProvidesAndRequiresFiltering/#_private_libraries I think the problem is worse here: since libffi isn't just a private ghc library it actually gets linked into some executables compiled by ghc as a runtime dependency. I was wondering if libffi could be statically linked into ghc's RTS, though I don't know how easy or possible/sufficient that is...? I can try to ask at least. I can show some examples from fedora packages if it helps. Of course at some point later or sooner ghc8.10 will get dropped from Rawhide, though I was still hoping to keep it around for a few more years.
Well we could try the filtering - it might still work - not planning to build anything in Fedora with ghc8.10 going forward anyway. The approach I tried to take was not to include libffi in the default ldconfig paths, but rather use ghc's only generated RPATH's load the libffi, so it might just work out.
(s/only/own)
Probably it should be fine (I haven't tried yet), but I won't be able to build it until the Koji builders adopt mock-4.0.
Looking at this again... I am feeling a bit conflicted. Could I even go the other way and add a ghc8.10-compat-libffi3.3 subpackage? :grimace: Currently an executable built with ghc8.10 will be linked against the bundled libffi.so.7. Users can install ghc8.10-base to satisfy the dependency. With libffi.so.8 already in Fedora 38 and Rawhide, is it less of a problem? (Also trying to ask upstream again about the possibility of static libffi linking, I suspect that may not work out.)
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.