Error building Swift 5.2

[futurejones]

I am trying to build Swift 5.2 on Raspbian Buster and get keep getting the following error.

/home/buildSwiftOnARM/swift/include/swift/AST/ImportCache.h:103:7: error: requested alignment is less than minimum alignment of 8 for type 'swift::namelookup::ImportCache'
class alignas(ModuleDecl::ImportedModule) ImportCache {
      ^
1 error generated.

[uraimo]

Yup, I hope this is the last one, tried a few things but haven't fixed it yet.

[DanBurkhardt]

++ needs a release update for swift-tools v5.2 on my end (paging @uraimo)

[finagolfin]

Any plans to put out a 5.3 build? I just put out a release for Android ARMv7, termux/termux-packages#5843, and you'll be happy to know it didn't require much patching (though I now see you hit that fd_set issue with SPM long before I did). There's still an issue with importing Macro constants from C headers in my 5.3 release, but otherwise works in my limited testing. Maybe we can work together and upstream our last fixes, as we seem to be the only people left building the toolchain for a 32-bit platform. 😆

[uraimo]

and you'll be happy to know it didn't require much patching (though I now see you hit that fd_set issue with SPM long before I did).

Hey @buttaface , quite happy indeed, since I see no problem in skipping 5.2 altogether and go straight to 5.3, I'll launch a build and see how it goes. Do the macros still partially work or are they completely broken (hope not)?

[finagolfin]

Do the macros still partially work or are they completely broken (hope not)?

I don't know to what extent, but I assume completely since basic constants like #define EXIT_SUCCESS 0 aren't recognized from stdlib.h. I know it finds that header since function declarations like clearenv() work, so it's just the Macro that's broken. I'm not familiar with ClangImporter so I'm going through it now to find this bug.

Does a basic Swift file like this compile with 5.1 on ARM?

import Glibc

let x: Int32 = clearenv()
print("got into this \(x)")
print("didn't get into this \(EXIT_SUCCESS)")

That works for me on AArch64, but with the Android ARMv7 compiler I get:

> ./swift-5.3-arm/usr/bin/swiftc macro.swift
macro.swift:6:31: error: cannot find 'EXIT_SUCCESS' in scope
print("didn't get into this \(EXIT_SUCCESS)")
                              ^~~~~~~~~~~~

[uraimo]

Can confirm it works with 5.1.5, I've aligned all the patches to 5.3 (added the static linking fix too as you did) and I'm building now. Are you sure that the patch for FSWatch is enough? It's only the first half of mine.

[finagolfin]

Can confirm it works with 5.1.5

Good to know, that means diffing that Swift ClangImporter source to 5.3 might turn up something, assuming you hit this bug with 5.3 too.

added the static linking fix too

Nice, use the original patch from the release/5.3 branch, not mine, as mine is tweaked a little to account for my other Android patches.

Are you sure that the patch for FSWatch is enough? It's only the first half of mine.

Yep, it's enough to build SPM, and that code is not tested normally or may not even be used for all I know. I'm suspicious that their code divides by different numbers for FD_SET vs. FD_ISSET, as that's not how those macros work in glibc or Bionic. I figured I'd look into making it work later, before trying to upstream that patch. Right now, that's enough to compile.

[uraimo]

as that's not how those macros work in glibc or Bionic. I figured I'd look into making it work later, before trying to upstream that patch.

I patched that more than one year ago but never added it upstream because a cleaner solution would have been to import that stuff in the swift glibc shim (takes more time 😅) instead of reimplementing it like they did in 5.0 (see #41)

[finagolfin]

Btw, the static stdlib patch I used is mostly apple/swift@e8fe229 combined with a one-line fix added later, apple/swift@da65420, and of course a couple Android tweaks.

[finagolfin]

Any luck with that build or is it still compiling? 😉

I tracked that Macro ClangImporter bug to when it's loading C modules in loadModuleClang(), both this call to CompilerInstance::loadModule() and the last call to Preprocessor::makeModuleVisible() don't actually seem to change those C modules' visibility in the 32-bit ARM build- found by sticking llvm::outs() << module->NameVisibility << '\n'; in a bunch of places in the swift ClangImporter, ie printf debugging- so it later can't find any visible Macro constants from those modules.

Since the same code works fine on AArch64, I don't know if this is a portability mixup somewhere or a codegen bug, as sticking those printfs in the relevant LLVM function called from CompilerInstance::loadModule(), ASTReader::makeModuleVisible(), says the module visibility has been set properly, but it isn't when going back to the Swift side. It will probably take stepping through with an actual debugger to figure that out, which you may be better situated to do than me.

Anyway, let me know if you hit the same bug with your glibc/ARM builds, could be a Bionic issue for all we know.

[uraimo]

Just finished a few seconds ago, both armv7 and armv6 still fail with the same error, very strange, I wonder what's different for the android target+your patches, nothing in the patches seems to be able to fix the error above.

[uraimo]

could be a Bionic issue for all we know.

This could also be some sort of regression introduced by the patch for the static linking issue, looking at the files it touches, hmm.

[uraimo]

Ok, noticed that an armv6 patch got applied to armv7 too, giving it another try, brb (6 hours).

[finagolfin]

both armv7 and armv6 still fail with the same error

Meaning you cannot import Macro constants too? Does hello world work? That is fine on Android ARMv7 and I'm also able to build a Swift package like swift-numerics with SPM, though building its tests fails.

[uraimo]

Sadly no, I still have the original alignment error reported here... and the last build failed again.

[finagolfin]

Is that alignas really necessary? Does it build if you remove it?

[finagolfin]

Here's the list of compiler flags used to compile lib/AST/ImportCache.cpp, which you can get by going into the Swift build directory and running ninja -t commands | ag AST/ImportCache.cpp: is your list any different?

-Wno-unknown-warning-option -Werror=unguarded-availability-new -fno-stack-protector -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-class-memaccess -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -Werror=switch -Wdocumentation -Wimplicit-fallthrough -Wunreachable-code -Woverloaded-virtual -O3 -fno-exceptions -fno-rtti -Werror=gnu -target armv7-none-linux-androideabi24 -O2 -g0 -funwind-tables -nostdinc++ -std=c++14

[uraimo]

It's probably still necessary since there are assertions that verify the alignment somewhere else in the source for this type (found them a few months ago), already tried removing it, without that a few things started to fail when compiling some files in the stdlib, es:

/home/buildSwiftOnARM/build/buildbot_linux/swift-linux-armv7/stdlib/public/core/4/Tuple.swift                            [23/1946]
---
3.      While evaluating request TypeCheckSourceFileRequest(source_file "/home/buildSwiftOnARM/swift/stdlib/public/core/KeyPath.swift")
4.      While type-checking 'AnyKeyPath' (at /home/buildSwiftOnARM/swift/stdlib/public/core/KeyPath.swift:37:8)
5.      While evaluating request EmittedMembersRequest(Swift.(file).AnyKeyPath@/home/buildSwiftOnARM/swift/stdlib/public/core/KeyPath.swift:37:14)
6.      While type-checking protocol conformance to 'Hashable' (at /home/buildSwiftOnARM/swift/stdlib/public/core/Hashable.swift:104:8) for type 'AnyKeyPath' (declared at [/home/buildSwiftOnARM/swift/stdlib/public/core/KeyPath.swift:37:8
- line:189:1] RangeText="class AnyKeyPath: Hashable, _AppendKeyPath {
  /// The root type for this key path.
  @inlinable
  public static var rootType: Any.Type {
    return _rootAndValueType.root
  }

  /// The value type for this key path.
  @inlinable
  public static var valueType: Any.Type {
    return _rootAndValueType.value
  }

  internal final var _kvcKeyPathStringPtr: UnsafePointer<CChar>?

  /// The hash value.
  final public var hashValue: Int {
    return _hashValue(for: self)
  }
  /// Hashes the essential components of this value by feeding them into the
  /// given hasher.
  ///
  /// - Parameter hasher: The hasher to use when combining the components
  ///   of this instance.
  @_effects(releasenone)
  final public func hash(into hasher: inout Hasher) {
    ObjectIdentifier(type(of: self)).hash(into: &hasher)
    return withBuffer {
      var buffer = $0
      if buffer.data.isEmpty { return }

If I remember correctly even removing all of these to see what's next, you hit one of those assertions on alignment.

The clang options are the same, I've just a few additional defines -DOBJC_OLD_DISPATCH_PROTOTYPES=0 -UNDEBUG -DSWIFT_ENABLE_RUNTIME_FUNCTION_COUNTERS and the target is obviously different.

[finagolfin]

Hmm, that is weird: are you compiling natively or cross-compiling? I'm doing the latter and I use the Android NDK clang to cross-compile the Swift compiler, so our different results could be because the Swift-forked clang acts differently.

I've now cross-compiled a debug build of the Swift compiler and will be tracing that C module visibility issue in lldb.

[uraimo]

Natively and in my case it should be using the llvm toolchain included with swift, another thing that could be happening is some wrongly sized field imported by some obscure include... yep, the setup is very different, anything could be happening. I'll take a look at it, np.

[finagolfin]

I just looked into it and the native build uses the host clang to build the Swift compiler, ie the same host clang used to compile the LLVM toolchain source shipped with Swift, the ninja command above should tell you which clang.

You could try building the Swift compiler with the freshly-built Swift-forked clang instead, by copying these two lines and pasting them here.

[finagolfin]

Fixed my Macro ClangImporter issue and seem to have a working toolchain on Android ARMv7, though I haven't run the Swift testsuite to make sure. My problem turned out to be a mismatch between the preprocessor defines set when compiling the LLVM backend versus the Swift frontend, you may want to double-check those defines for your build and see if that's a problem for you too.

[finagolfin]

Got my ARM patch merged upstream, apple/swift#34160, you may want to backport it to 5.3, as I do for my Android build, and try that.

[uraimo]

Thanks for the heads up... I've been kinda MIA lately but will be back.

[Jaelo]

I get this alignment error reported here when I am trying to build Swift 5.2.5 on Ubuntu server 20.04 (32 bits) with Raspberry PI 3B+. This error is it fixed? If so, where can I find the patch? Thanks in advance

[finagolfin]

No, it's not fixed, which is why this repo is still stuck at 5.1.5. I build the Swift toolchain for Android ARMv7 and haven't had that problem there, so it may be an issue in the glibc headers causing this, which isn't there in Android's BSD-derived Bionic libc.

[Jaelo]

Thanks for the info. I am going back to the Ubuntu focal's 64-bit release, for which swift 5.3 works.

[KittyMac]

I'm going to try and help fix this. I have a desire to use swift on some odroid boards here, and being stuck on 5.1.5 just won't cut it. I'm new to compiling swift itself, but i've done the following already:

1. followed a mix of futurejones and uraimo instructions; got 5.3 build to fail in the same place as above
2. I also tried hacking around the alignas(), that didn't get me very far
3. I tried buttaface's two comments a. i changed the build script to use the "freshly-built Swift-forked clang" (causes failures in swift-corelibs-libdispatch, error: implicit conversion from 'uint64_t' (aka 'unsigned long long') to 'long double' may lose precision [-Werror,-Wimplicit-int-float-conversion] ) b. i brought in the _LARGEFILE_SOURCE and _FILE_OFFSET_BITS=64 change (currently waiting for results)

I'm going to keep at it. If anyone has any ideas or hints I should try, please let me know.

[KittyMac]

While the scripts are building llvm, i noticed that it appears to be using the wrong triple argument

/usr/lib/llvm-6.0/bin/clang -cc1 -triple armv6kz-unknown-linux-gnueabihf -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name CodeGenModule.cpp ...

In other calls I see running I see it using the correct triple (armv7l). I am currently trying to track down where/why the wrong triple is happening.

[edit] Turns out I can build Swift 5.4 release without changes, but then it fails compiling Tuple.swift with assert for "Pointer is not sufficiently aligned". [/edit]

[KittyMac]

I was able to complete 5.4 build for amv7 in the following manner:

1. I used futurejones 5.3 "buildbot_linux,swiftlang-min" preset
2. i had to comment out the assert in llvm-project/llvm/include/llvm/ADT/PointerIntPair.h (pointer not sufficient aligned)
3. I had to add a couple of gcc ignores to /root/swift-source/swift-corelibs-libdispatch/src/benchmark.c

(I know for 2 better to find and fix the misaligned object, will get there but for now just wanted to get whole path building)

The build completes after that. Asking for version on swift works

root@odroid220:~/swift-source# swift --version
Swift version 5.4-dev (LLVM 7a20f40c45aca5d, Swift 031b848b7092c06)
Target: armv7-unknown-linux-gnueabihf

But simple built exectuable does not (I see there is ticket here already for similar)

root@odroid220:~# swiftc hello.swift 
root@odroid220:~# ls
hello  hello.swift  swapfile  swift-source
root@odroid220:~# ./hello 
./hello: error while loading shared libraries: libicudataswift.so.65: cannot open shared object file: No such file or directory

I feel I'm missing some install/setup step, will keep looking for it.

[edit] I believe the issue is as described here ( https://forum.qt.io/topic/67134/libicudata-so-57-not-found/3 ). I checked and libicudataswift.so is "soft-float" and the others are "hard-float", which would explain why the others load and this does not [/edit]

[edit] The issue with libicudataswift.so is the same as outlined here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653457#10 I applied the same two-line patch to libicu source/config/mh-linux and the hello runs, but segfaults. Trying buttaface's patch below now) [/edit]

[finagolfin]

Nice, check where the Swift stdlib is looking for ICU and if that's setup right, readelf -d [toolchain]/usr/lib/swift/linux/libswiftCore.so. I've been trying 5.4 on Android armv7 lately and had a problem in release mode (goes away with the debug, unoptimized stdlib), which was fixed by commenting out these four lines. If you have problems with hello world segfaulting once you fix the ICU issue and the backtrace indicates problems reading Swift runtime metadata, this may be the fix.

[KittyMac]

If you have problems with hello world segfaulting once you fix the ICU issue and the backtrace indicates problems reading Swift runtime metadata, this may be the fix.

I found the solution for the libicudata issue, and I do indeed hit a segfault when running hello world now that I've patched it. However, in my checkout I don't see the four lines you pointed to (i did update-checkout for release/5.4 ). should i be on a different version?

Program received signal SIGSEGV, Segmentation fault.
0xb6eac59c in swift::TargetMetadata<swift::InProcess>::getGenericArgs() const () from /root/swift-source/install/usr/lib/swift/linux/libswiftCore.so
(gdb) bt
#0  0xb6eac59c in swift::TargetMetadata<swift::InProcess>::getGenericArgs() const () from /root/swift-source/install/usr/lib/swift/linux/libswiftCore.so
#1  0xb6ec5bd4 in cacheCanonicalSpecializedMetadata(swift::TargetTypeContextDescriptor<swift::InProcess> const*, std::once_flag*)::$_21::__invoke(void*) ()
   from /root/swift-source/install/usr/lib/swift/linux/libswiftCore.so
#2  0xb6982784 in __pthread_once_slow (once_control=0xb6f8e7b0 <$ss23_ContiguousArrayStorageCMz>, init_routine=0xb68df4d9 <__once_proxy>) at pthread_once.c:116
#3  0xb6ee2030 in swift_once () from /root/swift-source/install/usr/lib/swift/linux/libswiftCore.so
#4  0xb6eba928 in swift_getCanonicalPrespecializedGenericMetadata () from /root/swift-source/install/usr/lib/swift/linux/libswiftCore.so
#5  0xb6e9b57c in __swift_instantiateCanonicalPrespecializedGenericMetadata () from /root/swift-source/install/usr/lib/swift/linux/libswiftCore.so
#6  0xb6e4c3b8 in $ss23_ContiguousArrayStorageCMa () from /root/swift-source/install/usr/lib/swift/linux/libswiftCore.so
#7  0xb6edbb00 in (anonymous namespace)::DecodedMetadataBuilder::createBoundGenericType(swift::TargetContextDescriptor<swift::InProcess> const*, __swift::__runtime::llvm::ArrayRef<swift::TargetMetadata<swift::InProcess> const*>, swift::TargetMetadata<swift::InProcess> const*) const () from /root/swift-source/install/usr/lib/swift/linux/libswiftCore.so
#8  0xb6ed90f0 in swift::Demangle::__runtime::TypeDecoder<(anonymous namespace)::DecodedMetadataBuilder>::decodeMangledType(swift::Demangle::__runtime::Node*) ()
   from /root/swift-source/install/usr/lib/swift/linux/libswiftCore.so
#9  0xb6ed829c in swift::Demangle::__runtime::TypeDecoder<(anonymous namespace)::DecodedMetadataBuilder>::decodeMangledType(swift::Demangle::__runtime::Node*) ()
   from /root/swift-source/install/usr/lib/swift/linux/libswiftCore.so
#10 0xb6ed6bb0 in swift_getTypeByMangledNodeImpl(swift::MetadataRequest, swift::Demangle::__runtime::Demangler&, swift::Demangle::__runtime::Node*, void const* const*, std::function<swift::TargetMetadata<swift::InProcess> const* (unsigned int, unsigned int)>, std::function<swift::TargetWitnessTable<swift::InProcess> const* (swift::TargetMetadata<swift::InProcess> const*, unsigned int)>) ()
   from /root/swift-source/install/usr/lib/swift/linux/libswiftCore.so
#11 0xb6ed69a4 in swift::swift_getTypeByMangledNode(swift::MetadataRequest, swift::Demangle::__runtime::Demangler&, swift::Demangle::__runtime::Node*, void const* const*, std::function<swift::TargetMetadata<swift::InProcess> const* (unsigned int, unsigned int)>, std::function<swift::TargetWitnessTable<swift::InProcess> const* (swift::TargetMetadata<swift::InProcess> const*, unsigned int)>) ()
   from /root/swift-source/install/usr/lib/swift/linux/libswiftCore.so
#12 0xb6ed700c in swift_getTypeByMangledNameImpl(swift::MetadataRequest, __swift::__runtime::llvm::StringRef, void const* const*, std::function<swift::TargetMetadata<swift::InProcess> const* (unsigned int, unsigned int)>, std::function<swift::TargetWitnessTable<swift::InProcess> const* (swift::TargetMetadata<swift::InProcess> const*, unsigned int)>) () from /root/swift-source/install/usr/lib/swift/linux/libswiftCore.so
#13 0xb6ed48e8 in swift::swift_getTypeByMangledName(swift::MetadataRequest, __swift::__runtime::llvm::StringRef, void const* const*, std::function<swift::TargetMetadata<swift::InProcess> const* (unsigned int, unsigned int)>, std::function<swift::TargetWitnessTable<swift::InProcess> const* (swift::TargetMetadata<swift::InProcess> const*, unsigned int)>) () from /root/swift-source/install/usr/lib/swift/linux/libswiftCore.so
#14 0xb6ed4b0c in swift_getTypeByMangledNameInContext () from /root/swift-source/install/usr/lib/swift/linux/libswiftCore.so
#15 0xb6fb3d00 in __swift_instantiateConcreteTypeFromMangledName () from /root/swift-source/install/usr/lib/swift/linux/libswiftSwiftOnoneSupport.so
#16 0xb6fb41cc in $ss27_allocateUninitializedArrayySayxG_BptBwlFyp_Tg5 () from /root/swift-source/install/usr/lib/swift/linux/libswiftSwiftOnoneSupport.so
#17 0x00400a3c in main ()

[finagolfin]

No, I didn't mention that that code was later reorganized and requires a different fix in trunk, but it's good to see you confirm it's not a bug specific to Android. The fix with 5.4 was to comment out the two calls to cacheCanonicalSpecializedMetadata instead, that got hello world and other small executables running again for me. Then I hit an issue with running swift build, where it would error out in a portion of the Swift stdlib that's written in Swift, ExistentialCollection.swift. No idea what's going on there yet.

[KittyMac]

The fix with 5.4 was to comment out the two...

Ah, excellent! That works now :)

root@odroid220:~/swift-source# /root/swift-source/install/usr/bin/swiftc --version
Swift version 5.4-dev (LLVM 7a20f40c45aca5d, Swift 031b848b7092c06)
Target: armv7-unknown-linux-gnueabihf
root@odroid220:~/swift-source# /root/swift-source/install/usr/bin/swiftc /root/hello.swift
root@odroid220:~/swift-source# ./hello 
Hello World
root@odroid220:~/swift-source# 

I'm going to drop back to 5.3 and get it to work there as well; then I'll try building some larger things to see how they fair.

[finagolfin]

I wouldn't bother with 5.3, as 5.4 is coming out in the coming week, since Apple always puts out a major Swift version in March.

[KittyMac]

Thanks, didn't know that. I have many of these odroids so i'm going to do in parallel anyway. I previously got 5.3 up to the libicudata problem, so am interested to see if it fixing that will help it go all the way.

[KittyMac]

5.3 working as well now.

root@odroid221:~# swiftc --version
Swift version 5.3-dev (LLVM 3093af41dd, Swift 3c8a284dd0)
Target: armv7l-unknown-linux-gnueabihf
root@odroid221:~# swiftc ./hello.swift && ./hello 
Hello World
root@odroid221:~# 

Now attempting to get swiftpm working (it was excluded in my preset for both). That's the final piece, then I can attempt to compile my actual project.

[finagolfin]

Great, one thing you may want to try before that is having build-script run the tests for each project, by adding the -T flag to the preset. I regularly run the Swift test suite when I build trunk on Android AArch64 and it gives me a good idea of where the compiler's at for the platform.

[KittyMac]

Great, one thing you may want to try before that is having build-script run the tests

Ok, I'm trying them both. Here are current issues, in case you have any pointers:

1. When adding test to the preset, I fail building here (assumably due to libatomic not being linked)

stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-armv7.dir/HeapObject.cpp.o:HeapObject.cpp:function swift_verifyEndOfLifetime: error: undefined reference to '__atomic_load'
stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-armv7.dir/HeapObject.cpp.o:HeapObject.cpp:function swift_release: error: undefined reference to '__atomic_load'
stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-armv7.dir/HeapObject.cpp.o:HeapObject.cpp:function swift_release: error: undefined reference to '__atomic_compare_exchange'
stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-armv7.dir/HeapObject.cpp.o:HeapObject.cpp:function swift_release: error: undefined reference to '__atomic_compare_exchange'
stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-armv7.dir/HeapObject.cpp.o:HeapObject.cpp:function swift_nonatomic_release: error: undefined reference to '__atomic_load'
stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-armv7.dir/HeapObject.cpp.o:HeapObject.cpp:function swift_nonatomic_release: error: undefined reference to '__atomic_compare_exchange'
stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-armv7.dir/HeapObject.cpp.o:HeapObject.cpp:function swift_nonatomic_release: error: undefined reference to '__atomic_load'
stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-armv7.dir/HeapObject.cpp.o:HeapObject.cpp:function swift_nonatomic_release: error: undefined reference to '__atomic_compare_exchange'
stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-armv7.dir/HeapObject.cpp.o:HeapObject.cpp:function swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::incrementUnownedNonAtomic(unsigned int): error: undefined reference to '__atomic_store'
stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-armv7.dir/HeapObject.cpp.o:HeapObject.cpp:function swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::decrementUnownedShouldFreeNonAtomic(unsigned int): error: undefined reference to '__atomic_store'
stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-armv7.dir/HeapObject.cpp.o:HeapObject.cpp:function swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::decrementUnownedShouldFreeNonAtomic(unsigned int): error: undefined reference to '__atomic_store'
stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-armv7.dir/RefCount.cpp.o:RefCount.cpp:function swift::HeapObjectSideTableEntry::tryIncrementNonAtomic(): error: undefined reference to '__atomic_store'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[100/104][ 96%][380.135s] Linking CXX executable unittests/Sema/swiftSemaTests

2. For swiftpm, I fail building at this point:

FAILED: lib/libTSCLibc.so Sources/TSCLibc/CMakeFiles/TSCLibc.dir/libc.swift.o swift/TSCLibc.swiftmodule 
: && /root/buildSwiftOnARM/install/usr/bin/swiftc -output-file-map Sources/TSCLibc/CMakeFiles/TSCLibc.dir/output-file-map.json -incremental -j 8 -emit-library -o lib/libTSCLibc.so -module-name TSCLibc -module-link-name TSCLibc -emit-module -emit-module-path swift/TSCLibc.swiftmodule -emit-dependencies -DTSCLibc_EXPORTS -module-cache-path "/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/tsc/module-cache" -g -swift-version 5  /root/buildSwiftOnARM/swift-tools-support-core/Sources/TSCLibc/libc.swift  -Xlinker -soname -Xlinker libTSCLibc.so    && :
<module-includes>:5:10: note: in file included from <module-includes>:5:
#include "/usr/include/utmp.h"
         ^
/usr/include/utmp.h:23:10: note: in file included from /usr/include/utmp.h:23:
#include <sys/types.h>
         ^
/usr/include/arm-linux-gnueabihf/sys/types.h:145:10: error: 'stddef.h' file not found
#include <stddef.h>
         ^
<unknown>:0: error: could not build C module 'SwiftGlibc'
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "LibcOverlayShims.h"

I tried slamming the path to the clang include dir in C_INCLUDE_PATH and CPLUS_INCLUDE_PATH, but that made it worse.

[finagolfin]

1. Yeah, that looks like missing libatomic: you'll want to revert the second change from the small pull that removed it, apple/swift#29581, but do it in the stdlib CMake config instead, ie find the file in stdlib/cmake that adds the pthread and dl libraries and add it back there. I'm told @drexin recently hit this on linux armv7 too, maybe he's working on an actual fix.
2. I hit this all the time on Android so I am very familiar with it: Swift looks for that C header in your toolchain in usr/lib/swift/clang, which could be a symbolic link or an actual directory copied over from clang depending on your build preset. Either way, make sure it points to or contains a directory with that header.

[finagolfin]

I tried the debug stdlib with --debug-swift-stdlib, to see if I could track down the remaining SPM issue on Android armv7, and SPM 5.4 finally worked, implying this is another optimization bug. I narrowed it down to commenting out those two caching calls and compiling the Swift portions of the stdlib with -Onone instead, to get a working but slow SPM. I will see if I can get the stdlib working with just changes to its compilation flags, then we can finally track down what source changes are needed to fix this in release mode.

[KittyMac]

ok, got the tests to run. Didn't get a chance to try on any other platform for comparison, but these are the results I got:

Testing Time: 1501.47s
  Unsupported      : 1644
  Passed           : 4881
  Expectedly Failed:   24
  Failed           :  500

[edit] Many of the failures have this in common:

/root/buildSwiftOnARM/build/buildbot_linux/swift-linux-armv7/test-linux-armv7/stdlib/Output/Runtime.swift.gyb.tmp.out: error while loading shared libraries: libicudataswift.so.65: cannot open shared object file: No such file or directory

So I suspect there is more to the libicudataswift fix I need to figure out. [/edit]

[KittyMac]

Ok, I fixed the libicudataswift thing (the unit tests didn't have it in the lib folder they point to so I just copied it over).

Testing Time: 1722.62s
  Unsupported      : 1644
  Passed           : 5326
  Expectedly Failed:   24
  Failed           :   55

A fair bit of that 55 seem to have "Not implemented relocation type!" in common.

[finagolfin]

That's a lot less tests run than I get on Android AArch64 (these test results were with the Mar. 2 trunk snapshot):

> ag "testsuite " build/Ninja-Release/swift-android-aarch64/swift-test-results/aarch64-unknown-linux-android/lit-tests.xml
3:<testsuite name="Swift(android-aarch64)" tests="6885" failures="2" skipped="293">
7569:<testsuite name="Swift(android-aarch64)" tests="6715" failures="129" skipped="1770">
36852:<testsuite name="Swift-Unit" tests="610" failures="1" skipped="0">

Once you want to move past that, you can test the corelibs by adding --skip-test-swift to the last command you ran.

[finagolfin]

Dario just merged two ARM pulls upstream that work around the atomic and metadata issues, apple/swift#36658 and apple/swift#36659, applying them to 5.4 will evade those problems. I also turned off the Swift optimizer when building the stdlib, to avoid the last SPM segfault and get a working toolchain again on Android armv7, though by slowing down Swift code like SPM with an unoptimized stdlib.

[KittyMac]

Ooh, those look like all the things I need; I am still stuck getting swiftpm to build, right now for missing libatomic link. I hope these help, because the places I've been adding it haven't made a dent yet. Thanks!

[KittyMac]

Got swiftpm to build! Made a simple executable package, compiled and ran it fine.

I had to use --debug-swift-stdlib. If I use just your -0none change I fail with unable to find module SwiftOnoneSupport. From my looking around that seems to be a special module built for that case, but there must be some additional toggle needed to get it to generate that I don't have on.

[finagolfin]

OK, I've been testing the armv7 SPM by building and testing a handful of Swift packages like swift-argument-parser with it, no problem, other than being slow.

--debug-swift-stdlib mostly does the same as my optimization flag change: that Onone library difference might be because you're natively compiling, while I'm cross-compiling the Swift toolchain and that library is there.

What happens if you build the Swift stdlib in release mode, do you get the same segfault I do when running the armv7 swift build?

[KittyMac]

When compiling release, I fail while compiling swiftpm when it tries to bootstap itself:

-- Build files have been written to: /root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/bootstrap
[20/20][100%][143.113s] Linking Swift executable bin/swift-test
--- bootstrap: note: Building SwiftPM (with a freshly built swift-build)
env SWIFTCI_USE_LOCAL_DEPS=1 SWIFTPM_MACOS_DEPLOYMENT_TARGET=10.15 LD_LIBRARY_PATH=/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/bootstrap/lib:/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/tsc/lib:/root/buildSwiftOnARM/build/buildbot_linux/llbuild-linux-armv7/lib:/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/yams/lib:/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/swift-argument-parser/lib:/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/swift-driver/lib:/root/buildSwiftOnARM/install/usr/lib/swift/linux SWIFT_EXEC=/root/buildSwiftOnARM/install/usr/bin/swiftc SWIFT_DRIVER_SWIFT_EXEC=/root/buildSwiftOnARM/install/usr/bin/swiftc SWIFTPM_PD_LIBS=/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/bootstrap/pm /root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/bootstrap/bin/swift-build --disable-sandbox --build-path /root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7 --configuration release -Xlinker -rpath -Xlinker $ORIGIN/../lib/swift/linux -Xswiftc -module-cache-path -Xswiftc /root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/module-cache -Xmanifest -module-cache-path -Xmanifest /root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/module-cache
--- bootstrap: error: Command '['env', 'SWIFTCI_USE_LOCAL_DEPS=1', 'SWIFTPM_MACOS_DEPLOYMENT_TARGET=10.15', u'LD_LIBRARY_PATH=/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/bootstrap/lib:/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/tsc/lib:/root/buildSwiftOnARM/build/buildbot_linux/llbuild-linux-armv7/lib:/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/yams/lib:/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/swift-argument-parser/lib:/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/swift-driver/lib:/root/buildSwiftOnARM/install/usr/lib/swift/linux', 'SWIFT_EXEC=/root/buildSwiftOnARM/install/usr/bin/swiftc', 'SWIFT_DRIVER_SWIFT_EXEC=/root/buildSwiftOnARM/install/usr/bin/swiftc', u'SWIFTPM_PD_LIBS=/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/bootstrap/pm', u'/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/bootstrap/bin/swift-build', '--disable-sandbox', '--build-path', '/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7', '--configuration', 'release', '-Xlinker', '-rpath', '-Xlinker', u'$ORIGIN/../lib/swift/linux', '-Xswiftc', '-module-cache-path', '-Xswiftc', '/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/module-cache', '-Xmanifest', '-module-cache-path', '-Xmanifest', '/root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/module-cache']' returned non-zero exit status -7
ERROR: command terminated with a non-zero exit status 1, aborting

ERROR: command terminated with a non-zero exit status 1, aborting

root@odroid220:~/buildSwiftOnARM# 

[finagolfin]

OK, you can try running that last bootstrapped swift build command manually in the swiftpm source directory or add -v to the SPM flags here to see the swallowed error output.

[KittyMac]

Using the verbose didn't work. Ran it manually said bus error. Ran with gdb and got:

Program received signal SIGILL, Illegal instruction.
0xb20ce9c6 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1

[finagolfin]

Probably the same Swift optimization issue then, if it doesn't happen with the debug stdlib.

[KittyMac]

With slow but working swiftpm I have been trying out different projects of mine. A lot of my smaller projects compiled and ran without issue, so I moved on to my biggest project.

I am currently getting this:

/usr/bin/ld.gold: error: /root/starbaseorion10/Server/.build/armv7-unknown-linux-gnueabihf/release/CJWTKitBoringSSL.build/crypto/poly1305/poly1305_arm_asm.S.o: multiple definition of 'openssl_poly1305_neon2_addmulmod'
/usr/bin/ld.gold: /root/starbaseorion10/Server/.build/armv7-unknown-linux-gnueabihf/release/CCryptoBoringSSL.build/crypto/poly1305/poly1305_arm_asm.S.o: previous definition here
/usr/bin/ld.gold: error: /root/starbaseorion10/Server/.build/armv7-unknown-linux-gnueabihf/release/CJWTKitBoringSSL.build/crypto/poly1305/poly1305_arm_asm.S.o: multiple definition of 'openssl_poly1305_neon2_blocks'
/usr/bin/ld.gold: /root/starbaseorion10/Server/.build/armv7-unknown-linux-gnueabihf/release/CCryptoBoringSSL.build/crypto/poly1305/poly1305_arm_asm.S.o: previous definition here

I believe what I want is to get the linker to be passed the --allow-multiple-definition flag. Didn't find where that might be tonight, going to continue looking tomorrow.

[finagolfin]

What version of clang are you compiling that assembly file with? Maybe you're hitting this issue, android/ndk#1409.

[KittyMac]

Adding -Xlinker --allow-multiple-definition to the swift build command got it to work. So I patched it in as a default here.

With that I got my project to build; ran it and confirmed it appears to be at least minimally working. I am hitting known performance problems, so I can confirm 5.4 did not magically fix them. From my quick peek last night, there seems to be a ton of 64bit bias in String which I suspect is an issue. Going to run some experiments and post results over there.

Thanks again for all the help!

[edit]note that it might also be slow because we're still building the debug version of swift stdlib, probably look into that first[/edit]

[KittyMac]

Back to the crash while building swiftpm on release, the SIGILL was a red herring. This is the actual crash:

Thread 1 "swift-build" received signal SIGBUS, Bus error.
0xb5b5df78 in swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::allocateSideTable(bool) ()
   from /root/buildSwiftOnARM/install/usr/lib/swift/linux/libswiftCore.so
(gdb) bt
#0  0xb5b5df78 in swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::allocateSideTable(bool) () from /root/buildSwiftOnARM/install/usr/lib/swift/linux/libswiftCore.so
#1  0xb5b5e048 in swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::formWeakReference() () from /root/buildSwiftOnARM/install/usr/lib/swift/linux/libswiftCore.so
#2  0xb5b29f88 in swift_weakInit () from /root/buildSwiftOnARM/install/usr/lib/swift/linux/libswiftCore.so
#3  0xb5d39f10 in $s8TSCBasic6ThreadC4taskACyyc_tcfc (task=..., self=...) at /root/buildSwiftOnARM/swift-tools-support-core/Sources/TSCBasic/Thread.swift:39
#4  0xb5d39de4 in $s8TSCBasic6ThreadC4taskACyyc_tcfC () from /root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/tsc/lib/libTSCBasic.so
#5  0xb5d15728 in $s8TSCBasic7ProcessC6launchyyKF (self=...) at /root/buildSwiftOnARM/swift-tools-support-core/Sources/TSCBasic/Process.swift:525
#6  0xb5d193f0 in $s8TSCBasic7ProcessC16checkNonZeroExit9arguments11environmentSSSaySSG_SDyS2SGtKFZ (arguments=..., environment=..., self=...) at /root/buildSwiftOnARM/swift-tools-support-core/Sources/TSCBasic/Process.swift:678
#7  0xb5d197a8 in $s8TSCBasic7ProcessC16checkNonZeroExit4args11environmentS2Sd_SDyS2SGtKFZ (args=..., environment=..., self=...) at /root/buildSwiftOnARM/swift-tools-support-core/Sources/TSCBasic/Process.swift:689
#8  0xb6cda720 in $s8Commands14SwiftBuildToolV17checkClangVersion33_2D7F84791E7904FA7BCA9664F5ADCF76LLyyF (self=...) at /root/buildSwiftOnARM/swiftpm/Sources/Commands/SwiftBuildTool.swift:115
#9  0xb6cda01c in $s8Commands14SwiftBuildToolV3runyyAA0bD0CKF (swiftTool=..., self=...) at /root/buildSwiftOnARM/swiftpm/Sources/Commands/SwiftBuildTool.swift:100
#10 0xb6ce15a4 in $s8Commands14SwiftBuildToolVAA0B7CommandA2aDP3runyyAA0bD0CKFTW () from /root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/bootstrap/lib/libCommands.so
#11 0xb6f30bd8 in $s8Commands12SwiftCommandPAAE3runyyKF (self=...) at /root/buildSwiftOnARM/swiftpm/Sources/Commands/SwiftTool.swift:238
#12 0xb6ce16a4 in $s8Commands14SwiftBuildToolV14ArgumentParser15ParsableCommandAadEP3runyyKFTW () from /root/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/bootstrap/lib/libCommands.so
#13 0xb6b3af9c in $s14ArgumentParser15ParsableCommandPAAE4mainyySaySSGSgFZ (arguments=..., self=...) at /root/buildSwiftOnARM/swift-argument-parser/Sources/ArgumentParser/Parsable Types/ParsableCommand.swift:95
#14 0xb6b3b0fc in $s14ArgumentParser15ParsableCommandPAAE4mainyyFZ (self=...) at /root/buildSwiftOnARM/swift-argument-parser/Sources/ArgumentParser/Parsable Types/ParsableCommand.swift:105
#15 0x00400c7c in main ()

[finagolfin]

I consistently have it failing in a different place on Android armv7 when the stdlib is optimized:

Swift/ExistentialCollection.swift:1129: Fatal error: Index type mismatch!
Current stack trace:                                                                                 0    libswiftCore.so                    0x00000000f6e1891c _swift_stdlib_reportFatalErrorInFile + 1121    libswiftCore.so                    0x00000000f6aae660 <unavailable> + 1144416
2    libswiftCore.so                    0x00000000f6aae9a8 <unavailable> + 1145256
3    libswiftCore.so                    0x00000000f6aad464 _assertionFailure(_:_:file:line:flags:) + 440
4    libswiftCore.so                    0x00000000f6b32b54 _RandomAccessCollectionBox.subscript.getter + 720
5    libswiftCore.so                    0x00000000f6aab1c8 <unavailable> + 1130952                   6    libswiftCore.so                    0x00000000f6bc0e98 <unavailable> + 2268824                   7    libswiftCore.so                    0x00000000f6b24c24 _print_unlocked<A, B>(_:_:) + 2424
8    swift-build                        0x00000000ab25e640 <unavailable> + 8078912

We will need to step through that in lldb to see what codegen the Swift compiler is optimizing wrong.

[KittyMac]

That's actually perfect; I applied a patch I found for the crash I reported. Now I am crashing with the same error you are.

Swift/ExistentialCollection.swift:1129: Fatal error: Index type mismatch!
Current stack trace:
0    libswiftCore.so                    0x00000000b5ad9158 swift_reportError + 44
1    libswiftCore.so                    0x00000000b5b54b24 _swift_stdlib_reportFatalErrorInFile + 108
2    libswiftCore.so                    0x00000000b57f7a00 <unavailable> + 1112576
3    libswiftCore.so                    0x00000000b57f7d58 <unavailable> + 1113432
4    libswiftCore.so                    0x00000000b57f6acc _assertionFailure(_:_:file:line:flags:) + 440

[KittyMac]

I switched back to work 5.3 dev and I seem to have a working release installation with it. All patches for 5.3 specifically can be found here. Moving on to testing it on some of my bigger projects now.

[edit] Tested my project, seems to run great; no performance issues as related in that other ticket[/edit]

[finagolfin]

Makes sense, as 5.3 works well for me on Android armv7, before these stdlib issues cropped up. You should probably look at re-enabling that LLVM pointer alignment error once you find what's triggering it. Since I don't hit it with Bionic, my guess is that something in a glibc header is throwing off some struct alignment on linux armv7.

[mickeyl]

Great work so far. 5.3 would be way better than 5.1, so could I ask you for a binary release?

The big things are coming forward with 5.5 though (async, actors, enhanced protocols and property wrappers), so it might as well make sense to skip 5.4 and have a look whether it would be possible to get some patches into mainline?

[finagolfin]

Getting back to this now, I suspect the stdlib assertion when optimized is related to that issue with prespecialized generic metadata: @KittyMac, did you try applying that upstream compiler pull that disabled it altogether? I'm going to try applying it and building the Swift 5.4 compiler from scratch.

[KittyMac]

@buttaface I haven't done any more since I got 5.3 working; its been working 100% for me so I've been content to move on.

Is this the patch you are referring to? I can give it a whirl and see if it fixes it.

[finagolfin]

Yep, that's the one: apply it instead of mine that modified stdlib/public/runtime/Metadata.cpp and see what happens with Swift 5.4. I'm almost done compiling a patched Swift 5.4 compiler for linux, then I will try cross-compiling the stdlib for Android armv7 with that metadata disabled and see what happens.

[finagolfin]

Yeah, that's it. Applying that compiler patch gets the Swift 5.4 stdlib working for me for Android armv7 again, I can use SPM to build and test packages again.

@drexin, what do you think about getting apple/swift#36658 merged into the 5.4 branch for the next point release?

[rvsrvs]

so if i pull the latest 5.4 release and apply that patch should i be able to build an armv7 swift compiler? or is there a list of other patches I need? having that is the first step in building my mac -> pi cross-compiler chain is why I ask. i'm hoping to teach on that next spring.

[KittyMac]

@buttaface happy to report that patch fixed it for me as well; Swift 5.4 on Ubuntu 18.04 armv7 release build. I compiled and ran my large swiftpm project without issue.

@rvsrvs I needed more than just this last patch. Full list of patches I used are on my fork here

[uraimo]

Sorry to drop in like this now guys, @KittyMac do you plan to open a PR to merge it (optional)? I'll spin up a build for armv6l but I expect it to work there too as usual.

[rvsrvs]

@KittyMac that's really nice. Pretty amusing how much of this is minor fixes to the build system and almost nothing required in actual code. did you also have to apply any patches from @uraimo or is your list complete?

[KittyMac]

@uraimo probably faster for you to just snatch the specific patches you need

@rvsrvs i only need the patches on that fork

[uraimo]

Thanks @KittyMac , I'm importing everything in a swift-5.4 branch and doing some test.

The legendary a92236 that has been there since 2015 for an llvm and a few other more related to syntax were not present in the dev branch so I'm going to verify if we still need them, likely not. This round I'm also dropping all the Ubuntu 16.04/Stretch stuff. @rvsrvs I'll merge that branch once I get at least an armv6 and an armv7 build done and tested, a few days.

[rvsrvs]

I noticed under 5.3 that there had been changes to the way the triples for the compiler were generated. Wonder if there's one now for arm6 so that I don't have to build an entire swift toolchain to cross-compile for the pi zero.

[KittyMac]

I built 5.5-05142021 yesterday (Ubuntu 18.04 armv7 release build); ran a simple actor/await/async thing, appeared to work.

[finagolfin]

I'm seeing segfaults when building with the latest Swift 5.5 June 13 source snapshot on Android armv7, some other issue has come up.

[finagolfin]

Alright, I have the Swift 5.5 source snapshots working again on Android armv7, some linker issues that shouldn't hit on linux.

Btw, @uraimo, someone on the forums was having problems building a recent NIO with Swift 5.1, some problem getting Swift 5.4 into the arm apt repos?

[rvsrvs]

fyi @uraimo the 5.4 branch builds on ubuntu focal armv7 out of the box. Doesn’t seem to build on Raspbian. Looking at why. And I can’t find the magic to get the Pi Zero to even successfully clone. Any advice?

[finagolfin]

I've been building Swift 5.5 just fine for Android armv7 with these patches, though most are for cross-compiling to Android. However, I'm seeing errors compiling the last trunk snapshot from Dec. 23 for Android armv7 (which is technically 5.7/6.0, since it's after the recent Swift 5.6 branch), patches here, when cross-compiling some C++ files in the Swift compiler. I have not looked into those issues, just a head's up that you may hit them too.

Update: this is the error I'm seeing, guessing it will hit you too.

[finagolfin]

Now that Swift 5.6 is out, I kicked off a build for Android armv7, which is still failing with the same compilation error:

llvm-project/llvm/include/llvm/ADT/PointerIntPair.h:148:3: error: static_assert failed due to requirement
'3U <= PointerUnionUIntTraits<swift::Expr *, swift::Stmt *, swift::Decl *, swift::Pattern *, swift::TypeRepr *,
llvm::MutableArrayRef<swift::StmtConditionElement> *, swift::CaseLabelItem *>::NumLowBitsAvailable'
"PointerIntPair with integer size too large for pointer"
  static_assert(IntBits <= PtrTraits::NumLowBitsAvailable,

It appears the compiler is trying to place a small integer into a pointer, a pointer union in this case, and failing to get enough space at compile-time, because the pointer union likely doesn't have enough bits available in a 32-bit pointer, as it normally would in a 64-bit pointer on common platforms.

Since this code is all fairly old and had been compiling for a while, my guess is that one of those constituent pointers changed last year, making less bits available to the pointer union.

If anyone is more familiar with these constexpr/template issues, let me know what you think. I try to avoid C++ as much as possible.

[finagolfin]

Found a later trunk commit by @xedin that fixes that compile-time issue, after a suggestion by @kateinoigakukun of what header to look at. I ran the resulting 5.6.1 toolchain for Android armv7 on my Android AArch64 phone and was able to build and test several Swift packages for armv7 without a problem.

[finagolfin]

@futurejones has announced an armv7 CI running on his AArch64 server on the Swift forum, though it currently fails when building the stdlib. He plans to take outside pulls to get that going, which I'll chip into, maybe others here will too. Perhaps he will make available those armv7 toolchain builds once it is working.