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.