Opened 22 months ago

Closed 3 months ago

#7942 closed bug (fixed)

aarch64 support in ghc

Reported by: jcapik Owned by:
Priority: high Milestone: 7.10.1
Component: Compiler Version:
Keywords: Cc: jdulaney@…, petersen, cjwatson@…, lukexi@…
Operating System: Linux Architecture: arm
Type of failure: GHC doesn't work at all Test Case:
Blocked By: Blocking:
Related Tickets: 7623, 8664 Differential Revisions:

Description

Hello.

Please, introduce the aarch64 support in ghc. The latest LLVM seems to support the aarch64 already.

Thanks in advance.

Regards,
Jaromir.

Attachments (3)

ghc-aarch64.patch (13.4 KB) - added by cjwatson 12 months ago.
add aarch64 support
0001-ARM64-support.patch (18.2 KB) - added by lukexi 5 months ago.
Finish ARM64 support
0001-Revert-change-to-alias-handling-in-ppLlvmGlobal-intr.patch (960 bytes) - added by lukexi 4 months ago.
Revert change to alias handling in ppLlvmGlobal introduced in d87fa34, which requires LLVM 3.6. As discussed in https://www.haskell.org/pipermail/ghc-devs/2014-November/007374.html

Download all attachments as: .zip

Change History (62)

comment:1 Changed 22 months ago by jcapik

  • Architecture changed from Unknown/Multiple to arm

comment:2 Changed 22 months ago by jdulaney

CCing myself.

To kick things off, here are links to a couple of relevant docs from ARM:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.genc010197a/index.html

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf

The first is the instruction set reference, the second is ELF ABI reference.

comment:3 Changed 22 months ago by jdulaney

  • Cc jdulaney@… added

comment:4 Changed 22 months ago by juhpetersen

  • Cc juhp@… added

comment:5 Changed 22 months ago by kgardas

  • Blocked By 7623 added

I'm not against working on this but first we need to have properly working x64-linux -> arm-linux cross-compiling tool chain on place which I'm not sure if it's working or not. So I mark this as blocking on #7623 for now.

comment:6 Changed 22 months ago by jdulaney

Fedora has a working cross compilation tool chain, and so does linaro.

comment:7 Changed 22 months ago by kgardas

I'm using linaro here for this, but the question is not about C cross-compilation tool-chain but about GHC LLVM-based cross-compilation support. If this is ready and working at least for ARM (as the most used cross-compilation target), then let's start working on it. If not, then let's first solve this homework...

comment:8 Changed 18 months ago by carter

  • difficulty set to Unknown
  • Milestone set to 7.10.1

adding arm64 support should probably be a goal for 7.10

maybe as one warm up task in the larger ABI evaluation project i've been trying to figure out.

comment:9 Changed 15 months ago by kgardas

  • Owner set to kgardas

Nobody stepped forward so far on this, so I'd like to give it a try myself.

comment:10 Changed 15 months ago by carter

for llvm or NCG?
for NCG, its kinda gated on first doing some NCG cleanup, (because theres a lot of copy pasta logic across the current NCG backends, and improving the engineering niceness of NCG will make such easier).

please feel welcome to hack out a prototype if you have the time, but please keep in mind that it may be easier after first cleaning up and refactoring NCG.

I *hope* to have the time to start hacking on that refactoring end of january onwards, though i hope other people collab on it too.

that said, if you mean LLVM specifically, go crazy! I think there may be some experimental support on GHC-IOS, but I could be wrong

Last edited 15 months ago by carter (previous) (diff)

comment:11 Changed 15 months ago by carter

adding LLVM AARCH64 support would be great for GHC-IOS too.

please reach out on ghc-devs / #ghc if you hit any problems or need any help

comment:12 Changed 15 months ago by kgardas

I'm following the same way like Stephen/David/me did ARM in the past: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/GHC_LLVMPorting
NCG way makes sense once you do have LLVM working, then you can try -fasm on smallest examples and do it step-by-step with increased example complexity.

comment:13 follow-up: Changed 15 months ago by carter

sounds reasonable. Will the arm 32 bit ghc calling convention make sense for AArch64? We may need to get a patch into llvm before having a distinct aarch64 abi. (and we should probably do some pretty thorough benchmarking before picking any such ABI)

Last edited 15 months ago by carter (previous) (diff)

comment:14 in reply to: ↑ 13 Changed 15 months ago by kgardas

Replying to carter:

sounds reasonable. Will the arm 32 bit ghc calling convention make sense for AArch64? We may need to get a patch into llvm before having a distinct aarch64 abi. (and we should probably do some pretty thorough benchmarking before picking any such ABI)

Not at all! aarch64 abi is completely different with completely different (or better nicely extended) register stack! So basically aarch64 is completely different beast than arm and I'm also doing it separately instead of extending current arm support.

W.r.t. benchmarking, I've also had such discussion with David few year ago, but then Stephen comes with work done so no benchmarking was done. The point is to find some sweet-spot inbetween using callee-saved regs for STG regs pinning and between leaving them for LLVM business usage...

Anyway, as I said, we're not there yet, although I already do have some code here. The problem is LLVM/AArch64 is not there yet as you can see from my bug report here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069248.html and that is just unregisterised build...

comment:15 Changed 15 months ago by carter

OK, so the near term is getting an unregisterized build working? thats still pretty awesome!

please holler once you get that working!

comment:16 follow-up: Changed 15 months ago by carter

@karel,
unregisterized builds use GCC specific C code, in which case you'll have to use GCC.

GCC 4.8 and newer, when built with multi target support, seems to have aarch 64 support.

clang/llvm wont work.

cheers
-Carter

comment:17 in reply to: ↑ 16 Changed 15 months ago by kgardas

Replying to carter:

@karel,
unregisterized builds use GCC specific C code, in which case you'll have to use GCC.

GCC 4.8 and newer, when built with multi target support, seems to have aarch 64 support.

clang/llvm wont work.

cheers
-Carter

Carter, this is misunderstanding IMHO. I'm not dealing with unregisterised via C, but instead with unregisterised via LLVM build here. Please read the GHC/LLVM porting document I linked above for more information.

comment:18 Changed 15 months ago by carter

@karel, step 1 of that link says "make sure the unregisterized C build works"
:)

comment:19 Changed 15 months ago by kgardas

@carter: but -fvia-C is no longer supported, at least, https://ghc.haskell.org/trac/ghc/wiki/Building/Porting suggests that. So LLVM is the only way for AArch64 as we do not have NCG ready for this platform...

comment:20 Changed 15 months ago by carter

no, -fvia-C still works, i know (because i broke it accidentaly early fall)

comment:21 Changed 15 months ago by kgardas

  • Blocked By 8664 added

comment:22 Changed 15 months ago by kgardas

Good! So this LLVM bug above shows only on PrimoptWrappers and I've been able to compile this file without -fllvm as Carter points out above. So here is bindist's HelloWorld running on AArch64/ARM64 platform:

root@localhost:~# ./HelloWorld 
Hello world!root@localhost:~# file HelloWorld 
HelloWorld: ELF 64-bit LSB executable, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.7.0, BuildID[sha1]=0x5301662c82ccd3fe7c3f1486ac10d0f13b2f54c9, not stripped
root@localhost:~# uname -m
aarch64
root@localhost:~# 

comment:23 Changed 14 months ago by kgardas

  • Owner kgardas deleted

comment:24 Changed 12 months ago by cjwatson

I've been working with Karel Gardas (kgardas) to get this going, and I've now completed an unregisterised GHC bootstrap on Ubuntu arm64. I started by cross-building GHC 7.8 using variations on Karel's patch set, and then bodged together a GHC 7.6 build (since that's what we're shipping on other architectures) bootstrapping off that. This all now appears to be working fine and I should be able to get binaries into our archive in the next few days.

I'm attaching a patch (made against the ghc-7.8 branch); most of it is Karel's from https://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc-head-build-for-arm64-platform/, I've just tweaked it a bit given that I had the advantage of access to real hardware. Some of this may be unnecessary for an unregisterised build, but it doesn't hurt. It would be great if somebody could review and apply it, since it's a lot easier to get started on more advanced things like LLVM or NCG support if you don't have to do the time-consuming bootstrap yourself. Please note that you also need to update the embedded copy of libffi in libffi-tarballs/ to at least version 3.0.12.

Karel's initial patch caused GHC_CONVERT_CPU to return arm64. I changed this to aarch64, since the return value of GHC_CONVERT_CPU is used to construct the --host option for configure scripts and thus it needs to be valid as the first part of a GNU config triplet. I left the Haskell-level architecture name as ArchARM64, since that style is more common as a user-facing name for the architecture: for example, the Linux kernel returns arm64 in its uname output.

Changed 12 months ago by cjwatson

add aarch64 support

comment:25 Changed 12 months ago by cjwatson

  • Cc cjwatson@… added
  • Status changed from new to patch

comment:26 Changed 12 months ago by kgardas

Colin, thanks for submitting this. Indeed, I think for basic unregisterised build to work changes done in includes/stg/ and rts/ may be omitted for now. Those are my experimental bits kind of start of a work on registerised support...

comment:27 Changed 12 months ago by cjwatson

Right. I thought that was probably the case, but I didn't really want to do yet another build that omitted them in order to make sure, since it all takes a while as it is!

comment:28 Changed 11 months ago by thoughtpolice

  • Blocked By 7623, 8664 removed
  • Resolution set to fixed
  • Status changed from patch to closed
  • Version 7.6.3 deleted

This has been merged in c29bf984dd20431cd4344e8a5c444d7a5be08389 - thank you Colin!

comment:29 Changed 10 months ago by nomeata

Can we get this into 7.8.3 or 7.8.4? Debian will have to add this patch anyways, and I’m always keen on reducing delta.

comment:30 Changed 8 months ago by lukexi

Hi folks,
I'm trying to use this to get ARM64 compilation working for iOS and am running into this:

"inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-DNOSMP -optc-DUSE_LIBFFI_FOR_ADJUSTORS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\"rts_v\" -optc-w -static  -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -optc-DNOSMP -dcmm-lint      -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen           -O2    -c rts/StgCRun.c -o rts/dist/build/StgCRun.o

rts/StgCRun.c:789:24:
     error: index must be an integer in range [-256, 255].
            STG_RETURN ":\n\t"
                           ^

<inline asm>:13:16:
     note: instantiated into assembly here
            ldr lr, [sp], #16384
                          ^
1 error generated.

(I made a couple of other changes, changing bx to br and references to ip0 and ip1 to x16 and x17, to get things this far)

Does that make sense to anyone?
Thanks!

comment:31 Changed 8 months ago by lukexi

This is with LLVM HEAD, via brew install llvm --all-targets --with-clang --HEAD

comment:32 Changed 8 months ago by carter

LLVM HEAD IS BUSTED with CURRENT GHC HEAD and ALL GHC RELEASES

fyi.

comment:33 Changed 8 months ago by carter

llvm 3.4 should be kosher currently. Ben Gamari started some work on updated llvm bits, but thats not done yet

comment:34 Changed 8 months ago by lukexi

Yep, I'm using Ben's branch to get LLVM HEAD working in general. I can get a build to complete just fine if I mangle the ASM in StgCRun.c but haven't made it actually work yet.

I'm not sure that 3.4 has full ARM64 support (i.e. works on iOS)...

comment:35 Changed 8 months ago by lukexi

OK, so if I replace the offending call with

"ldr lr, [sp]\n\t"
"add sp, sp, %3\n\t"

(which I believe should be functionally equivalent)

I can compile, but then get a crash running on the device here:

HelloHaskell`StgRun:
0x1004cea34:  stp    x28, x27, [sp, #-96]!
0x1004cea38:  stp    x26, x25, [sp, #16]
0x1004cea3c:  stp    x24, x23, [sp, #32]
0x1004cea40:  stp    x22, x21, [sp, #48]
0x1004cea44:  stp    x20, x19, [sp, #64]
0x1004cea48:  stp    fp, lr, [sp, #80]
0x1004cea4c:  stp    x19, x20, [sp, #-16]!
0x1004cea50:  stp    x21, x22, [sp, #-16]!
0x1004cea54:  stp    x23, x24, [sp, #-16]!
0x1004cea58:  stp    x25, x26, [sp, #-16]!
0x1004cea5c:  stp    x27, x28, [sp, #-16]!
0x1004cea60:  stp    x16, x17, [sp, #-16]!
0x1004cea64:  str    lr, [sp, #-8]!
0x1004cea68:  str    lr, [sp, #16384]     <------------EXC_BAD_ACCESS (code=259, address=0x16fdcf7a8)
0x1004cea6c:  mov    x19, x1
0x1004cea70:  br     x0

comment:36 Changed 8 months ago by kgardas

So basically you try to cross-compile using registerised GHC? If so, then I'm afraid nobody hacked LLVM to support GHC specific calling convention on ARM64 yet! If unregisterised, then you IMHO you should not be in this part of code which is IMHO just for registerised builds. Also if you attempt unregisterised, I would advice to use gcc and not llvm i.e. -fvia-C and not -fllvm for the start.

comment:37 Changed 8 months ago by lukexi

Ah, that's it! I was wondering if that was done yet.

OK, we better get on that then : D

Thanks so much for getting this started!

comment:38 Changed 8 months ago by kgardas

One general note: the code in StgCRun written for ARM64 was probably written by me (I've provided the patch to Colin). So if this is this code, then please be assured that this code *never* has run on ARM64. It was written just from reading doc and as a first attempt to add support for registerised ARM64. At that time I've finished with this since I had not machine, ARM's foundation model was really slow and LLVM project was just before big merge from ARM's own AArch64 and Apple's own ARM64 LLVM backends together.
Although the situation now looks way much better, at least both LLVM backends were merged together and even some hardware appears this all still means that if nobody has done it yet, then someone needs to do quite a lot. When I've been working on ARM port with Stephen, David helped me a lot and we wrote following LLVM/porting guide. I would recommend to read it: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/GHC_LLVMPorting

comment:39 Changed 8 months ago by lukexi

Hi Karel,
That's really helpful — well it's run on ARM64 /now/ : D

If you (and Stephen, David and Manuel) are up for it I'd love to work on it. Maxwell Swadling, who helped Stephen and I finish up GHC iOS, is in too.

I'll read through that doc, thanks!

comment:40 follow-up: Changed 6 months ago by juhpetersen

(another +1 for NCG for arm and arm64! :-)

Likely I should open a new ticket, but I am having trouble with
installing ghc-7.8.3 plus above patch on Fedora 21 ARM64 (aarch64).

"inplace/bin/ghc-cabal" copy libraries/haskell2010 dist-install "strip" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' 'v dyn '
Installing library in
/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/haskell2010-1.1.2.0
"/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc-pkg" --force --global-package-db "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/package.conf.d" update rts/dist/package.conf.install
Reading package info from "rts/dist/package.conf.install" ... done.
rts-1.0: Warning: library-dirs: /usr/lib64/ghc-7.8.3/rts-1.0 doesn't exist or isn't a directory
rts-1.0: Warning: include-dirs: /usr/lib64/ghc-7.8.3/include doesn't exist or isn't a directory
rts-1.0: cannot find any of ["libHSrts.a","libHSrts.p_a","libHSrts-ghc7.8.3.so","libHSrts-ghc7.8.3.dylib","HSrts-ghc7.8.3.dll"] on library path (ignoring)
"inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc-pkg" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' NO  
Warning: cannot determine version of
/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc-pkg
:
""
Registering ghc-prim-0.3.1.0...
"inplace/bin/ghc-cabal" register libraries/integer-gmp dist-install "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc-pkg" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' NO  
Warning: cannot determine version of
/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc-pkg
:
""
ghc-cabal: Installed package ID not registered: "ghc-prim-0.3.1.0-inplace"
ghc.mk:901: recipe for target 'install_packages' failed
Makefile:64: recipe for target 'install' failed
make[1]: *** [install_packages] Error 1
make: *** [install] Error 2

The problem seems to be that the installed (dynlinked) ghc-pkg does no output anything!
(eg "ghc-pkg --version" returns "", same for --help.)

When I try the built binaries I find that
ghc-7.8.3/utils/ghc-pkg/dist/build/tmp/ghc-pkg (which is statically linked)
works normally (ie it outputs --help and --version) whereas
$DESTDIR/$libdir/ghc-7.8.3/bin/ghc-pkg gives no output on stdout!

Maybe I should try installing statically linked ghc and see if that makes difference.

comment:41 Changed 6 months ago by juhpetersen

  • Cc petersen@… added; juhp@… removed

comment:42 in reply to: ↑ 40 ; follow-up: Changed 6 months ago by juhpetersen

Replying to 40:

Maybe I should try installing statically linked ghc and see if that makes difference.

Unfortunately the DYNAMIC_GHC_PROGRAMS=NO build fails already in the build phase:

:
cat utils/hpc/hpc.wrapper                                     >> inplace/bin/hpc
chmod +x                                                     inplace/bin/hpc
Reachable modules from DynFlags out of date
Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780)
Redundant modules: Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 FastBool Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream
compiler/ghc.mk:640: recipe for target 'compiler/stage2/dll-split.stamp' failed
make[1]: *** [compiler/stage2/dll-split.stamp] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:64: recipe for target 'all' failed
make: *** [all] Error 2

comment:43 Changed 6 months ago by slyfox

Looks like dll-split fails on ghci-less build on almost everything #9552.
I propose to disable fatal error there in disabled ghci case
(I'll try to come with a patch this weelend for it).

comment:44 in reply to: ↑ 42 Changed 6 months ago by slyfox

Replying to juhpetersen:

Unfortunately the DYNAMIC_GHC_PROGRAMS=NO build fails already in the build phase:

Redundant modules: Bitmap BlockId ...

With #9552 being hopefully fixed as

https://git.haskell.org/ghc.git/commitdiff/2a8ea4745d6ff79d6ce17961a64d9013243fc3c6

you should pass that stage.

comment:45 Changed 6 months ago by juhpetersen

Thanks slyfox! That fixed my DYNAMIC_GHC_PROGRAMS=NO build. :)

comment:46 Changed 6 months ago by lukexi

I sent a mail out to the list a bit ago but should have added a comment here:

I've completed the work to add the GHC ARM64 calling convention to LLVM [1], and finished up the support in GHC itself [2]. I'm in the process of tidying up the patches for submission. I'm going to try to backport them to 7.8 as well.

[1] https://github.com/lukexi/llvm
[2] https://github.com/lukexi/ghc

comment:47 Changed 5 months ago by juhpetersen

  • Cc petersen added; petersen@… removed

Thanks lukexi! That sounds great!

Anyway I reported the current problems with building ghc-7.8.3 on aarch64 earlier in #9673.

comment:49 Changed 5 months ago by lukexi

Thanks Carter!

I've got one more patch to push up — I implemented the necessary functions from SMP.h in ARM64 ASM while backporting the ARM64 support to 7.8 (as I needed it... though I'm not sure that will be deemed worthy of inclusion in 7.8.4 since it relies on the LLVM 3.5 support)

comment:50 Changed 5 months ago by lukexi

  • Cc lukexi@… added
  • Priority changed from normal to high
  • Resolution fixed deleted
  • Status changed from closed to new
  • Type changed from feature request to bug

Changed 5 months ago by lukexi

Finish ARM64 support

comment:51 Changed 5 months ago by lukexi

  • Status changed from new to patch

Hello! This patch finishes ARM64 support including SMP and means we can now run on the newest 64-bit iOS devices. Would be awesome to get this into 7.10.

comment:52 Changed 4 months ago by Austin Seipp <austin@…>

In d87fa343cd5d298c9fea96d65d05a20929ff97d0/ghc:

arm64: 64bit iOS and SMP support (#7942)

Signed-off-by: Austin Seipp <[email protected]>

comment:53 Changed 4 months ago by thoughtpolice

  • Resolution set to fixed
  • Status changed from patch to closed

Merged, thanks Luke!

Changed 4 months ago by lukexi

Revert change to alias handling in ppLlvmGlobal introduced in d87fa34, which requires LLVM 3.6. As discussed in https://www.haskell.org/pipermail/ghc-devs/2014-November/007374.html

comment:54 Changed 4 months ago by lukexi

  • Resolution fixed deleted
  • Status changed from closed to new

comment:55 Changed 4 months ago by lukexi

  • Status changed from new to patch

comment:56 Changed 4 months ago by thoughtpolice

  • Resolution set to fixed
  • Status changed from patch to closed

comment:57 Changed 4 months ago by nomeata

  • Resolution fixed deleted
  • Status changed from closed to new

I noticed that this did not make it into 7.8.4-rc1. I thought that’s what "merged in ..." meant... but now I see that you did not merge the amd64 support, but rather some alias handling.

Marking this as merge in case this is just an oversight, and there was a plan to merge the AMD64 support in 7.8.4. Just close it again if that was not the intention.

comment:58 Changed 4 months ago by nomeata

  • Status changed from new to merge

comment:59 Changed 3 months ago by thoughtpolice

  • Resolution set to fixed
  • Status changed from merge to closed

Yes, leaving AArch64 in 7.10 only was the intention; no 7.8.4. Sorry for the confusion.

Note: See TracTickets for help on using tickets.