Created attachment 525189 [details] Enable armv7hl arch in ghc.spec ghc have been bootstrapped on armv7hl Fedora 15. The attached changes enables the armv7hl architecture in ghc.spec Note, this touches the logic on selection of registerised builds a bit. I have verified build.mk still gets correctly set on x86_64 but have not verified a full x86_64 build or i386.
This also means that armv7hl needs to be added as supported arch on all haskell packages shortly. This armv7hl support applies to F15, F16 and rawhide.
Thanks - I merged the changes into git pkg git for f15, f16 and f17. I am thinking if we need to rebuild all of the f15 ghc packages anyway then it is probably a good excuse to backport 7.0.4 to f15 at the same time. Anyway here is the 7.0.2 build for f15: http://koji.fedoraproject.org/koji/taskinfo?taskID=3384551 Could you test that it builds ok for you in mock on armv7hl?
Thanks. Mock build queued. Should have the result within 16 hours.
ghc-7.0.2-16.4.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/ghc-7.0.2-16.4.fc15
(In reply to comment #3) > Thanks. Mock build queued. Should have the result within 16 hours. Awesome, and thanks for doing this! :) I went ahead and pushed the build towards f15 updates-test since I would like the other changes to have wider testing anyway as well. If this one is no good on armv7hl then I'll push a another build to koji.
Thanks for the patch. I had a couple comments/questions on it (I don't think they are so important so don't worry too much). -# use system libffi +# use system libffi (currently requires ghci in compiler/ghc.cabal it seems) I think it is the other way: for ghci, libffi is required. %if %{with libffi} +# Is this really needed? It's also added in .mk files. SRC_HC_OPTS += -lffi %endif AFAICT yes, but happy to be proven wrong. The rest looks fine to me and already merged. :)
Those two comments is about problems relating to the Fedora patch to use system provided libffi instead of the normal bundled copy. THe first comment is about that on the primary arches ghc is patched to use the system provided libffi, but on armv7hl and presumably ppc64 as well this then fails to find ffi.h during stage1 compile. And my guess is that it's due to differences in how libffi is referenced when ghci is enabled as that was the only clue I could find in the .mk files to why it could fail to find ffi.h on arm but not x86. More investigation is needed to fully identify why if fails to properly reference the system provided libffi header location in unregisterised builds without ghci. The second comment is from the fact that libffi is always referenced and linked, even when not using the system provided copy (a bundled copy is then used). It should not be needed to add -lffi globally only because the system provided libffi is used. The same -lffi is also added by the .mk files in modules where libffi is needed. I have not yet tried to build without the added -lffi (need to solve the first issue first). These are notes from unsuccessfully trying to build ghc using system provided libffi instead of the bundled copy on armv7hl. As you probably know, bundling libraries like this is against packaging guidelines for good reasons. Regards Henrik
ghc-7.0.2-16.4.fc15 built without errors on armv7hl.
Package ghc-7.0.2-16.4.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ghc-7.0.2-16.4.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/ghc-7.0.2-16.4.fc15 then log in and leave karma (feedback).
(In reply to comment #7) > The first comment is about that on the primary arches ghc is patched to use the > system provided libffi, but on armv7hl and presumably ppc64 as well this then > fails to find ffi.h during stage1 compile. And my guess is that it's due to > differences in how libffi is referenced when ghci is enabled as that was the > only clue I could find in the .mk files to why it could fail to find ffi.h on > arm but not x86. More investigation is needed to fully identify why if fails to > properly reference the system provided libffi header location in unregisterised > builds without ghci. I see. The patch comes from debian - it really needs to be upstreamed but for better or worse upstream is little concerned about this. > The second comment is from the fact that libffi is always referenced and > linked, even when not using the system provided copy (a bundled copy is then > used). It should not be needed to add -lffi globally only because the system > provided libffi is used. The same -lffi is also added by the .mk files in > modules where libffi is needed. Good point. > I have not yet tried to build without the added -lffi (need to solve the first > issue first). These are notes from unsuccessfully trying to build ghc using > system provided libffi instead of the bundled copy on armv7hl. Ok I will try to see if I can build for rawhide without -lffi. I think we have only succeeded building the libffi patch for primary arch's. > As you probably know, bundling libraries like this is against packaging > guidelines for good reasons. Indeed: I keep to use the system lib on all archs but just haven't time to work on that.
The patch also seems to mysteriously break some of the testsuite ffi tests on i686 BTW... hmm. (In reply to comment #8) > ghc-7.0.2-16.4.fc15 built without errors on armv7hl. Great - so I assume the basic tests in the .spec file ran ok than - but it would be very good if you could try to build something with the built package to be sure it is not broken. Does it have ghci?
> > I have not yet tried to build without the added -lffi (need to solve the first > > issue first). These are notes from unsuccessfully trying to build ghc using > > system provided libffi instead of the bundled copy on armv7hl. > > Ok I will try to see if I can build for rawhide without -lffi. > I think we have only succeeded building the libffi patch for primary arch's. It built fine for me on my F15 x86_64 machine. So thanks - I am removing the -lffi in ghc-7.0.4-30.fc17. > Indeed: I [want] to use the system lib on all archs but just haven't time > to work on that. (In reply to comment #11) > The [system-libffi] patch also seems to mysteriously break some of the testsuite > ffi tests on i686 BTW... hmm. ps If you have any suggestions for how to speed up the ARM build, I am all ears.
Package ghc-7.0.2-16.5.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ghc-7.0.2-16.5.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/ghc-7.0.2-16.5.fc15 then log in and leave karma (feedback).
ghc-7.0.2-16.5.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.