Bug 2174157
| Summary: | ghc8.10 exports rpm-based provides for libffi. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Carlos O'Donell <codonell> |
| Component: | ghc8.10 | Assignee: | Jens Petersen <petersen> |
| Status: | POST --- | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 39 | CC: | petersen |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2123772 | ||
|
Description
Carlos O'Donell
2023-02-28 18:25:38 UTC
(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. |