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 swiftlang/swift@e8fe229 combined with a one-line fix added later, swiftlang/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, swiftlang/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]

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 swiftlang/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.

[finagolfin]

@colemancda just announced a build of the latest Swift 5.7.1 release for linux armv7, try it out and let him know how it works there.

[colemancda]

@buttaface I have been working with @futurejones in the Swift ARM Slack and he was been updating his repos with my binaries.

[finagolfin]

Good to hear your build will be added to Neil's repos. Personally, I hate Slack and avoid it as much as possible. I'd be happy to communicate over email or something else instead.