lang/ghc: Update bootstrap on arm to 8.10.7
ClosedPublic
Actions

Authored by mikael on Sep 27 2021, 11:07 AM.

Details

Reviewers

Commits

R11:c57db8f4ded8: lang/ghc: Update arm bootstrap to 8.10.7

Summary

Update bootstrap on arm to 8.10.7
Pass --host to the configure script otherwise ghc thinks we are crosscompiling (only affects armv6 and armv7)
Remove CONFIGURE_ENV, it is now handled in patch-aclocal.m4 (submitted upstream as https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6599)

Diff Detail

Repository

R11 FreeBSD ports repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

mikael requested review of this revision.Sep 27 2021, 11:07 AM

mikael created this revision.

Looks good, thanks for upstreaming the patch!

Did you upload bootstraps somewhere?

This revision is now accepted and ready to land.Sep 27 2021, 11:42 AM

In D32155#725720, @arrowd wrote:

Looks good, thanks for upstreaming the patch!

Did you upload bootstraps somewhere?

Yes, they are on freefall:/home/mikael/ghc

Closed by commit R11:c57db8f4ded8: lang/ghc: Update arm bootstrap to 8.10.7 (authored by Mikael Urankar <mikael@FreeBSD.org>). · Explain WhyOct 1 2021, 12:51 PM

This revision was automatically updated to reflect the committed changes.

Mikael Urankar <mikael@FreeBSD.org> added a commit: R11:c57db8f4ded8: lang/ghc: Update arm bootstrap to 8.10.7.

markmi_dsl-only.net added a subscriber: markmi_dsl-only.net.Aug 24 2022, 5:04 AM

markmi_dsl-only.net added inline comments.

lang/ghc/Makefile
203	So CONFIGURE_ENV_BOOTSTRAP, if non-empty (i.e, ${BOOT_LLVM_VERSION} != ${LLVM_VERSION}), overrode CONFIGURE_ENV 's LLC, OPT, CLANG, and CC for phase_0_build, phase_1_build, and final? In such a context, LLVM_VERSION validly went unused for all phases for all 4 of the related commands generated? And, after the change, phase_0_build, phase_1_build, and final instead now ignore LLVM_VERSION and BOOT_LLVM_VERSION relative to llc, opt, clang, and cc commands, even when ${BOOT_LLVM_VERSION} != ${LLVM_VERSION} ? Is this expected to be appropriate for modern enough llvm* ?