Re: Package fails to build for aarch64, works for x86_64

[Stephen Smoogen <ssmoogen@xxxxxxxxxx>]

On Thu, 21 Sept 2023 at 10:24, Ron Olson <tachoknight@xxxxxxxxx> wrote:

Hey all-

I was trying to submit the released version of Swift 5.9 to Fedora but I get a build failure only for the aarch64 platform for Rawhide and F39:

https://koji.fedoraproject.org/koji/buildinfo?buildID=2291751 (F39)
https://koji.fedoraproject.org/koji/buildinfo?buildID=2291750 (Rawhide/F40)

While it compiled for both fine on F38:

https://koji.fedoraproject.org/koji/buildinfo?buildID=2291752

What is the rule/advice around a situation like this insofar as should I release it for the current platforms (F38,F37,EPEL9) and try to figure out what’s going on with the aarch64 build, or should it be an all-or-nothing, release to every platform or none at all? I’d personally lean towards trying to provide the new shiny where possible, but I can see making a case for holding off due to F39 coming down the road. Complicating all this is trying to gauge interest in there being an aarch64 version of Swift for Fedora.

In general it is never a good idea to have newer versions of a release in older Fedora releases than in newer releases. I would release for EPEL9 and try to work with other developers on why it is failing on F39/F40 . They both seem to fail for the same reasons

swift::irgen::LinkEntity, llvm::Function *, llvm::DenseMapInfo<swift::irgen::LinkEntity>, llvm::detail::DenseMapPair<swift::irgen::LinkEntity, llvm::Function *>>::moveFromOldBuckets(BucketT *, BucketT *) [DerivedT = llvm::DenseMap<swift::irgen::LinkEntity, llvm::Function *>, KeyT = swift::irgen::LinkEntity, ValueT = llvm::Function *, KeyInfoT = llvm::DenseMapInfo<swift::irgen::LinkEntity>, BucketT = llvm::detail::DenseMapPair<swift::irgen::LinkEntity, llvm::Function *>]: Assertion `!FoundVal && "Key already in new map?"' failed.

Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace.
Stack dump:
0. Program arguments: /builddir/build/BUILD/swift-source/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend 

...

1. Swift version 5.9 (swift-5.9-RELEASE)
2. Compiling with the current language version
3. While evaluating request IRGenRequest(IR Generation for module _StringProcessing)
4. While emitting metadata for 'OpCode' (at /builddir/build/BUILD/swift-source/swift-experimental-string-processing/Sources/_StringProcessing/Engine/Instruction.swift:25:3)
 #0 0x0000000006227940 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/builddir/build/BUILD/swift-source/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend+0x6227940)
 #1 0x00000000062259b8 llvm::sys::RunSignalHandlers() (/builddir/build/BUILD/swift-source/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend+0x62259b8)
 #2 0x0000000006227d58 SignalHandler(int) Signals.cpp:0:0
 #3 0x0000ffff9bba87f0 (linux-vdso.so.1+0x7f0)
 #4 0x0000ffff9aeff038 __pthread_kill_implementation (/lib64/libc.so.6+0x8f038)
 #5 0x0000ffff9aeb5680 gsignal (/lib64/libc.so.6+0x45680)
 #6 0x0000ffff9aea0284 abort (/lib64/libc.so.6+0x30284)
 #7 0x0000ffff9aeae46c __assert_fail_base (/lib64/libc.so.6+0x3e46c)
 #8 0x0000ffff9aeae4e0 __assert_perror_fail (/lib64/libc.so.6+0x3e4e0)
 #9 0x0000000000a52368 llvm::DenseMapBase<llvm::DenseMap<swift::irgen::LinkEntity, llvm::Function*, llvm::DenseMapInfo<swift::irgen::LinkEntity, void>, llvm::detail::DenseMapPair<swift::irgen::LinkEntity, llvm::Function*>>, swift::irgen::LinkEntity, llvm::Function*, llvm::DenseMapInfo<swift::irgen::LinkEntity, void>, llvm::detail::DenseMapPair<swift::irgen::LinkEntity, llvm::Function*>>::moveFromOldBuckets(llvm::detail::DenseMapPair<swift::irgen::LinkEntity, llvm::Function*>*, llvm::detail::DenseMapPair<swift::irgen::LinkEntity, llvm::Function*>*) DLangDemangle.cpp:0:0

...

<unknown>:0: error: unable to execute command: Aborted
<unknown>:0: error: compile command failed due to signal 6 (use -v to see invocation)

The funny thing is that Apple has already started providing development versions of Swift 5.10 and it does, in fact, build on both x86_64 and aarch64.

Ron
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

--

Stephen Smoogen, Red Hat Automotive

Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue