Recommended way to develop for Amazon Linux 2023?

Server Development
21

I don't see why not.

That all depends if there will be another 5.9 patch release, and if @mishal_shah is willing to take a late addition, considering it has already been delayed or canceled.

I think you should be able to get it into release/5.10, particularly if you get AL2023 approved as an official platform.

Pretty much, changing this line to (targetTriple.os == .linux && targetTriple.vendor == .amazon) || targetTriple.environment == .android {, after adding amazon to the list of recognized vendors and parser below, should work for the new swift-driver, while similar changes here should update the old C++ Driver.

1 Like
22

do we, as community contributors, have the authority to approve a new official platform in the first place?

23

I don't think in this instance it's necessary to get hung up on the platform support "approval" part; The core team can be asked about this and since we have been supporting Amazon Linux and this is work to not "break this support in the new version". The problem here has been to getting it to work, which is that this thread and y'all are making happen :slight_smile:

The formalities of "approving the platform" can follow a functional support of given platform after all.

This is not the same discussion as e.g. adding a completely different Linux distro, it is continued support of AL really.

6 Likes
24

@sebsto @taylorswift @Finagolfin I have had some recent success building amazonlinux 2023 using the lld linker.
The lld linker is available as a dnf install so it can easily be added to build dependencies.

I have posted a release and details of the build and patches required here -

There are docker images and rpm install packages available for swift-5.8.1-release and swift-5.9.2-release as well.

2 Likes
25

Nice, thanks for all the work you do around Swift on AArch64.

I notice you are not building the new swift-syntax parser, so macros won't be enabled for your builds. Have you tried installing the existing AL2 builds, as @taylorswift and @sebsto did, and using those to build the Swift portions of the Swift compiler? Also, are you sure that target.py file you are patching in foundation is actually used anywhere? I've never touched it and never had a problem, and the Android NDK switched to lld years ago.

26

Using the existing AL2 builds won't work because it needs to have gold linker installed.

I have tried using the new AL2023 5.81 build to bootstrap a 5.9.2 build but was running into a lot of clang-13 errors - ld.lld: error: undefined hidden symbol: __start_swift5_protocols

Not 100% sure about the target.py , I will do some more test builds to confirm, but still want to eliminate all references to the gold linker.

27

Gold is only the default, you can override that to use lld when building the compiler. Alternately, you can use the macro-less AL2023 builds you just produced, as you tried.

Huh, I fixed that a couple years ago with Swift 5.8. Can you check the failing commands to see if those flags are being added?

Pretty sure you don't have to bother with references in unused build scripts. :smile:

28

@Finagolfin I found the issue with the clang-13 errors - ld.lld: error: undefined hidden symbol: __start_swift5_protocols

This fix is in main only, not 5.9 or 5.10

I have patched the file in 5.9 and now I am able to bootstrap 5.9 with the 5.8 toolchain and everything is building as expected.

I will upload a new swift-5.9.2-release toolchain tomorrow.

2 Likes
29

Thank you @futurejones for having distributed these builds.

This is great work !

I think we should not "hard patch" the CMake and CLang code to use lld instead of gold but we should test for Amazon Linux and return one of the two values instead.

These changes should go upstream in the Swift and Clang repo.

@Finagolfin @mishal_shah @ktoso how can we make that happen before the cut off date for Swift 6 ?

30

Simply submit the pulls which make the driver changes we discussed above and we should be able to get them in. As for CMake changes, I don't know if CMake can detect AL2023 as the build host, but if it can, just check that and change the linker used to build the Swift compiler to lld there too.

31

@sebsto yes I agree, my patches were only intended to enable a successful build not for a PR.

I am working on more suitable code and hopefully will have some updated patches and PR's submitted soon.

I personally believe that we should be making lld the default linker, not gold. Especially now, as we are bootstrapping new builds with an existing swift toolchain that already includes the lld linker.

1 Like
32

I started the discussion about lld vs gold with folks at Apple and it looks like everybody agrees on this long term objective. Now a decision has to be taken :-)
It's likely that a team at Apple will propose the required code changes for ALI2023.

33

is there any reason to prefer lld over the regular GNU ld? i have been using the latter for about a week now and have not noticed any issues so far.

34

I think he main benefit is build speed.

See the recent mold linker benchmark (in the README).

lld is roughly height time faster then ld (and gold is just a little faster than ld)

1 Like
35

Unless the plan is to switch the default for all Unix platforms over to lld, which most non-linux platforms like Android and the BSDs have already done, before the 6.0 branch, I suggest you get those AL2023-specific pulls in yourself.

Yep, in addition, we can remove the dependency on GNU binutils, since all those smaller tools are shipped with the Swift toolchain anyway, just not used by default yet. I have also been pushing for the default librarian archiver used by the compiler on Unix to be llvm-ar, not ar from binutils, and have already switched over the upcoming SwiftPM 5.10 to use it.

36

@sebsto
I have just submitted #PR72049.
Let me know what you think.