Debian packaging support #60690

melizasw · 2022-08-22T04:18:08Z

@buttaface suggested that I start a new issue here to discuss problems that arise while I am packaging Swift for Debian. I have found the Fedora packaging that @tachoknight has done to be very helpful in this effort. A related work that I just learned of from @etcwilde is work on packaging for Ubuntu in the swift-installer-scripts repo.

The challenges are mainly getting Swift to build into a .deb package using the debuild tool and getting the packing into compliance with Debian policy. It has a very powerful linting tool that checks for many common errors and issues and most Debian Developers won't sign off on a package that isn't lint clean or reasonably close to it.

Here is the biggest issue that I know of right now. The file ConvertUTF.cpp uses a non-free license and is located in three places:

indexstore-db/lib/LLVMSupport/Support/ConvertUTF.cpp
llbuild/lib/llvm/Support/ConvertUTF.cpp
llvm-project/llvm/lib/Support/ConvertUTF.cpp

Debian suggests replacing these files with libicu, which is already a part of Swift. But there are other alternatives out there as well such as utfcpp.
I am not a software engineer by trade so it is unlikely that I could make this replacement on my own without making a mess of things.

Another linting error that I can probably resolve post-bulid on my own is that many libraries have executable permissions. For example:
E: swiftlang: shared-library-is-executable 0755 [usr/libexec/swift/lib/clang/10.0.0/lib/linux/libclang_rt.dyndd-x86_64.so]

And another example of how challenging this packaging can be, I can't strip the binaries or REPL won't work and when I disable the binary stripping the lint tool then complains that the binaries have not been stripped. sigh

The text was updated successfully, but these errors were encountered:

finagolfin · 2022-08-22T04:38:33Z

The file ConvertUTF.cpp uses a non-free license and is located in three places

That file is under the same University of Illinois Open Source License as a lot of LLVM code. In addition, it requires that disclaimer from Unicode, Inc. in the source, not sure why a simple disclaimer is such a problem.

Since that file is compiled as part of the LLVM support library libLLVMSupport.a, which is presumably already in some Debian LLVM package, you can probably just copy what they do for that existing Debian package here.

I can't strip the binaries or REPL won't work and when I disable the binary stripping the lint tool then complains that the binaries have not been stripped

Surely Debian allows exceptions for developer tools like this that need those symbols to work?

melizasw · 2022-08-22T05:28:29Z

The file ConvertUTF.cpp uses a non-free license and is located in three places

That file is under the same University of Illinois Open Source License as a lot of LLVM code. In addition, it requires that disclaimer from Unicode, Inc. in the source, not sure why a simple disclaimer is such a problem.

Since that file is compiled as part of the LLVM support library libLLVMSupport.a, which is presumably already in some Debian LLVM package, you can probably just copy what they do for that existing Debian package here.

I am able to see what they put in their copyright file and will do the same thing. The lint error will just have to be overridden. I see a lot of familiar lint errors in that llvm package so maybe this won't be as big of an issue as I had thought.

I can't strip the binaries or REPL won't work and when I disable the binary stripping the lint tool then complains that the binaries have not been stripped

Surely Debian allows exceptions for developer tools like this that need those symbols to work?

I'm sure they do. I was just complaining how this turns into a three step process of disabling the stripping, disabling the lint errors that result, then probably having to explain to a Debian Developer why stripping was disabled.

Once I have the low hanging lint errors cleaned up I'll start working on getting the remaining errors reviewed by a Debian Developer to see if they have any concerns that I need to address.

melizasw · 2022-08-23T00:44:09Z

Here is something else that would help me. Anything that lintian flags as an error is considered to be either a bug in the lint tool or a Debian policy violation. That said, it seems like there is some understanding that it isn't always that simple and overrides of rules are allowed.

For the following lintian errors it would be very helpful to know if the error is something I should be able to fix, or is expected. And if expected, what is the reason why. Any explanation that I can add to the comments of the lintian overrides will help to get approval to add the package to Debian. Most errors have multiple failures, but only the first is shown for brevity.

E: swift source: binary-with-bad-dynamic-table [llvm-project/llvm/test/tools/llvm-xray/X86/Inputs/elf64-objcopied-instrmap.bin]
N: 
N:   This appears to be an ELF file. According to readelf, the program headers
N:   suggests it should have a dynamic section, but readelf cannot find it.
N:   
N:   If it is meant to be external debugging symbols for another file, it
N:   should be installed under /usr/lib/debug. Otherwise, this could be a
N:   corrupt ELF file.

E: swiftlang: custom-library-search-path RUNPATH swift_5.6.2/build/buildbot_linux/llvm-linux-x86_64/lib [usr/libexec/swift/bin/lldb-argdumper]
N: 
N:   The binary or shared library sets RPATH or RUNPATH. This overrides the
N:   normal library search path, possibly interfering with local policy and
N:   causing problems for multilib, among other issues.
N:   
N:   The only time a binary or shared library in a Debian package should set
N:   RPATH or RUNPATH is if it is linked to private shared libraries in the
N:   same package. In that case, place those private shared libraries in
N:   /usr/lib/*package*. Libraries used by binaries in other packages should be
N:   placed in /lib or /usr/lib as appropriate, with a proper SONAME, in which
N:   case RPATH/RUNPATH is unnecessary.
N:   
N:   To fix this problem, look for link lines like: gcc test.o -o test
N:   -Wl,--rpath,/usr/local/lib or gcc test.o -o test -R/usr/local/lib and
N:   remove the -Wl,--rpath or -R argument. You can also use the chrpath
N:   utility to remove the RPATH.
N: 
N:   Please refer to https://wiki.debian.org/RpathIssue for details.

This should be pretty easy for me to fix if this is just an artifact of packaging and not a responsibility of the swift build scripts.

E: swift source: missing-notice-file-for-apache-license [swift-crypto/NOTICE.txt]
N: 
N:   The package appears to be licensed under the Apache 2.0 license and a
N:   NOTICE file (or similar) exists in the source tree. However, no files
N:   called NOTICE or NOTICE.txt are installed in any of the binary packages.
N:   
N:   The Apache 2.0 license requires distributing of such files:
N:   
N:    (d) If the Work includes a "NOTICE" text file as part of its
N:        distribution, then any Derivative Works that You distribute must
N:        include a readable copy of the attribution notices contained
N:        within such NOTICE file [..]
N:   
N:   Please include the file in your package, for example by adding
N:   path/to/NOTICE to a debian/package.docs file.
N: 
N:   Please refer to usr/share/common-licenses/Apache-2.0 for details.

E: swiftlang: no-code-sections [usr/libexec/swift/lib/swift_static/linux/libicudataswift.a]
N: 
N:   
N:   The named members of the static library have no usable code sections.
N:   
N:   It happens when shared objects are built with -flto=auto but without
N:   -ffat-lto-objects. dh_strip strips the LTO sections but may leave the
N:   static library without any usable code.
N: 
N:   Please refer to Bug#977596 for details.

These don't need to be executable do they? I'm not even sure just how they are getting +x.

E: swiftlang: shared-library-is-executable 0755 [usr/libexec/swift/lib/clang/13.0.0/lib/linux/libclang_rt.asan-x86_64.so]
N: 
N:   Shared libraries should be mode 0644.
N: 
N:   Please refer to Run-time shared libraries (Section 8.1) in the Debian
N:   Policy Manual for details.

There are many of this kind. I'm not sure what the issue is as they don't go into the package. Maybe there is a way to clean them up just prior to running lintian?

E: swift source: source-is-missing [cmake/Tests/CMakeTests/ELF/elf32lsb.bin]
N: 
N:   The source of the following file is missing. Lintian checked a few
N:   possible paths to find the source, and did not find it.
N:   
N:   Please repack your package to include the source or add it to
N:   "debian/missing-sources" directory.
N:   
N:   Please note, that very-long-line-length-in-source-file tagged files are
N:   likely tagged source-is-missing. It is a feature not a bug.

This is just a warning, but it makes me wonder if I built Swift incorrectly? Maybe it doesn't matter as this is pertaining to the debug symbol package (swiftlang-dbgsym_5.6.2-1_amd64.deb) and I don't think that would be getting added.

W: swiftlang-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/00/bb2a059d939872ab355e8fa581567eac042f7d.debug]
N: 
N:   The binary is installed as a detached "debug symbols" ELF file, but it
N:   does not appear to have debug information associated with it.
N:   
N:   A common cause is not passing -g to GCC when compiling.
N:   
N:   Implementation detail: Lintian checks for the ".debug_line" and the
N:   ".debug_str" sections. If either of these are present, the binary is
N:   assumed to contain debug information.
N: 
N:   Please refer to Bug#668437 for details.

If anyone can help make sense of any of these lintian issues that would be most helpful.

finagolfin · 2022-08-23T04:16:59Z

The test files, elf64-objcopied-instrmap.bin and elf32lsb.bin, I'm not sure why your linter is even looking at those: you're not running the tests and those files are not installed at the end, are they? The first one is from LLVM, so I'd look at how the existing package handles that.
The RUNPATH issue is a definite bug on our end, specifically with lldb to have an absolute path like that. Please look into where that's getting added, and I bet the LLVM devs would accept a patch to remove that.
The missing license file may be an oversight on our end, unsure as pretty much all Swift repos use that same Apache license, not sure why your linter is pointing just that one out.
The ICU issue needs to be investigated, could be legit. You could also try removing the Swift build of libicu and just use the Debian system package, which should work too but ~~will~~may require you to bump the Swift package anytime the system libicu is updated.
Those libcompiler-rt shared libraries don't need executable permissions, probably a mistake on our end.
I have no idea about that debug file with no symbols, haven't used that.

melizasw · 2022-08-23T07:17:13Z

The test files, elf64-objcopied-instrmap.bin and elf32lsb.bin, I'm not sure why your linter is even looking at those: you're not running the tests and those files are not installed at the end, are they? The first one is from LLVM, so I'd look at how the existing package handles that.

I looked up Debian's llvm-toolkit-14 package and wouldn't you know it, they have these same lintian errors and many of the others that I am seeing. If they can have them in llvm then swift should be allowed them as well. The lint tool looks at both the completed package as well as the source, so it seems to pick up all sorts of files that shouldn't matter.

* The `RUNPATH` issue is a definite bug on our end, specifically with lldb to have an absolute path like that. Please look into where that's getting added, and I bet the LLVM devs would accept a patch to remove that.

I'm going to look into this some more, but maybe it isn't an issue. Based on the Debian wiki this forces the use of the custom Swift libraries, which I presume is better than picking up the system's libraries for llvm and others. Again, the Debian llvm package has these errors as well so I will contact the maintainer to find out what I can.

* The missing license file may be an oversight on our end, unsure as pretty much all Swift repos use that same Apache license, not sure why your linter is pointing just that one out.

For now I'm going to let the Debian build scripts copy over the file and see if that resolves things.

* The ICU issue needs to be investigated, could be legit. You could also try removing the Swift build of libicu and just use the Debian system package, which should work too but ~will~may require you to bump the Swift package anytime the system libicu is updated.

Well, wouldn't you know it. Debian's libicu-dev package has the exact same error on libicudata.a. So I guess nothing to worry about there.

* Those libcompiler-rt shared libraries don't need executable permissions, probably a mistake on our end.here

I was able to get those fixed by manually running chmod at the appropriate place in the Debian packaging flow. There is a tool that is supposed to fix this automatically for me so maybe it has a bug. I will have to look into that. At no point in the build process do I see the swift tools setting these files to anything but 0644 and they don't become 0755 until they are copied out into the final directory structure so I'm not sure yet who is doing it.

* I have no idea about that debug file with no symbols, haven't used that.

Yah, probably not an issue.

I've just realized that the person that originally wanted to package Swift for Debian back in 2015 was and is a Debian Developer with the LLVM packaging team. If I can pique his interest to sponsor/mentor this package then he already has half of the answers and might even jump at the opportunity to get involved with it again. Crossing my fingers!

melizasw · 2022-08-27T16:47:48Z

I'm at the point of trying to get a Debian Developer to sponsor my package and clean up any policy violations. The violation that was discovered first is that there is an existing Debian packaged named "python3-swiftclient" and they supply a binary named "swift". Since their binary does something completely different I am not allowed to have a binary named "swift" no matter how unlikely it is for someone to want to use the swift that is designed for server object storage and also compile Swift programs on that same server. I could use the "conflict" mechanism to prevent my package and theirs from being installed at the same time, but policy does not allow that unless the binaries provide the same functionality.

The recommended action is to contact the debian-devel mailing list to start a discussion of who has to change their name, or if both have to change their name. At the same time I could ask for an exception to the "conflict" mechanism rule.

I guess my main question here is that since "swift" and "swiftc" are both just symbolic links to "swift-frontend" could I drop "swift" from my package and thus require Debian users to always call swiftc instead? Would that break anything other than reams of documentation?

finagolfin · 2022-08-29T11:30:40Z

since "swift" and "swiftc" are both just symbolic links to "swift-frontend" could I drop "swift" from my package and thus require Debian users to always call swiftc instead?

swift has two purposes: it invokes the REPL when run alone and it interprets a Swift file when given one. As such, you could always drop it as long as you don't care about those two uses, or look into renaming it instead.

Would that break anything other than reams of documentation?

No, I doubt there's even that much doc on it.

melizasw · 2022-08-30T03:11:20Z

I don't know yet if this will be allowed by the Debian policy, but what I have done is create a set of scripts such that during the installation process if /usr/bin/swift does not exist the user is presented with a prompt asking if they wish to add it or not. If an actual binary file is located at /usr/bin/swift instead of a symbolic link then a message is printed out warning that "swift" already exists and it cannot be used to call the Swift REPL or compiler/interpreter.

melizasw · 2022-08-31T16:20:50Z

I've been copying /usr/bin/ls to /usr/bin/swift to test the Debian package install in the case where the "swift" package is installed. If I forget to remove this copy before building Swift then it tries to build newswiftdriver with /usr/bin/swift and fails with a less than helpful message. I'm not sure what all I can do on my end to address this (and may not need to do anything), but I'm wondering if Swift can do a sanity check on /usr/bin/swift before trying to build with it. At a minimum it could verify that it is indeed Swift and is past some minimum version since we know Swift 5.5.1 won't work.

finagolfin · 2022-08-31T16:30:57Z

I'm wondering if Swift can do a sanity check on /usr/bin/swift before trying to build with it. At a minimum it could verify that it is indeed Swift and is past some minimum version since we know Swift 5.5.1 won't work.

Are you sure the compiler build even uses swift and not swiftc? If so, feel free to submit a pull to do that sanity check for the swift toolchain build.

melizasw · 2022-08-31T21:05:56Z

Are you sure the compiler build even uses swift and not swiftc? If so, feel free to submit a pull to do that sanity check for the swift toolchain build.

I tried to reproduce this error on a Swift 5.5.1 build, but was unable to. Here is the log file from trying to build Swift 5.6.2 when Swift is not installed but /usr/bin/swift is some other binary than Swift (copied from /usr/bin/ls in this case):

swift/utils/build-script --preset=buildbot_linux,no_test install_destdir=/home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2 installable_package=/home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2/swiftlang_5.6.2-1-debian.tar.gz
[swift/utils/build-script] NOTE: using preset "buildbot_linux,no_test", which expands to 

swift/utils/build-script --assertions --swift-enable-ast-verifier=0 --no-swift-stdlib-assertions '--swift-install-components=autolink-driver;compiler;clang-resource-dir-symlink;stdlib;swift-remote-mirror;sdk-overlay;parser-lib;toolchain-tools;license;sourcekit-inproc' '--llvm-install-components=llvm-cov;llvm-profdata;IndexStore;clang;clang-resource-headers;compiler-rt;clangd;lld;LTO' --llbuild --swiftpm --swift-driver --xctest --libicu --libcxx --swiftdocc --build-ninja --install-llvm --install-swift --install-lldb --install-llbuild --install-swiftpm --install-swift-driver --install-xctest --install-libicu --install-prefix=/usr --install-libcxx --install-sourcekit-lsp --install-swiftdocc --build-swift-static-stdlib --build-swift-static-sdk-overlay --build-swift-stdlib-unittest-extra --test-installable-package --toolchain-benchmarks --install-destdir=/home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2 --installable-package=/home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2/swiftlang_5.6.2-1-debian.tar.gz --relocate-xdg-cache-home-under-build-subdir --build-subdir=buildbot_linux --lldb --release --test --validation-test --long-test --stress-test --test-optimized --foundation --libdispatch --indexstore-db --sourcekit-lsp --swiftdocc '--lit-args=-v --time-tests' --lldb-test-swift-only --install-foundation --install-libdispatch --reconfigure --skip-test-cmark --skip-test-lldb --skip-test-swift --skip-test-llbuild --skip-test-swiftpm --skip-test-swift-driver --skip-test-xctest --skip-test-foundation --skip-test-libdispatch --skip-test-playgroundsupport --skip-test-libicu --skip-test-indexstore-db --skip-test-sourcekit-lsp --skip-test-swiftdocc

[swift/utils/build-script] NOTE: Using toolchain default
+ cmake --version
+ mkdir -p /home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2/build/buildbot_linux
+ rm -rf /home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2/build/buildbot_linux/ninja-build
+ cp -r /home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2/ninja /home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2/build/buildbot_linux/ninja-build
+ pushd /home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2/build/buildbot_linux/ninja-build
+ env CXX=/usr/bin/clang++ /usr/bin/python3 configure.py --bootstrap
[1/29][  3%][0.045s] INLINE build/browse_py.h
[2/29][  6%][0.057s] CXX build/debug_flags.o
[3/29][ 10%][0.635s] CXX build/browse.o
[4/29][ 13%][0.787s] CXX build/depfile_parser.o
[5/29][ 17%][0.971s] CXX build/disk_interface.o
[6/29][ 20%][1.180s] CXX build/clparser.o
[7/29][ 24%][1.208s] CXX build/edit_distance.o
[8/29][ 27%][1.449s] CXX build/dyndep.o
[9/29][ 31%][1.652s] CXX build/deps_log.o
[10/29][ 34%][2.033s] CXX build/clean.o
[11/29][ 37%][2.073s] CXX build/line_printer.o
[12/29][ 41%][2.137s] CXX build/dyndep_parser.o
[13/29][ 44%][2.163s] CXX build/build_log.o
[14/29][ 48%][2.252s] CXX build/lexer.o
[15/29][ 51%][2.430s] CXX build/graphviz.o
[16/29][ 55%][2.691s] CXX build/metrics.o
[17/29][ 58%][2.967s] CXX build/version.o
[18/29][ 62%][3.019s] CXX build/eval_env.o
[19/29][ 65%][3.108s] CXX build/string_piece_util.o
[20/29][ 68%][3.210s] CXX build/parser.o
[21/29][ 72%][3.246s] CXX build/util.o
[22/29][ 75%][3.353s] CXX build/graph.o
[23/29][ 79%][3.606s] CXX build/subprocess-posix.o
[24/29][ 82%][3.873s] CXX build/manifest_parser.o
[25/29][ 86%][3.964s] CXX build/build.o
[26/29][ 89%][4.120s] CXX build/state.o
[27/29][ 93%][4.192s] AR build/libninja.a
[28/29][ 96%][4.692s] CXX build/ninja.o
[29/29][100%][4.813s] LINK ninja
bootstrapping ninja...
warning: A compatible version of re2c (>= 0.11.3) was not found; changes to src/*.in.cc will not affect your build.
wrote build.ninja.
bootstrap complete.  rebuilding...
+ popd
--- Building earlyswiftdriver ---
Traceback (most recent call last):
  File "/home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2/swift/utils/build-script", line 722, in <module>
    sys.exit(main())
  File "/home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2/swift/utils/build-script", line 717, in main
    return main_normal()
  File "/home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2/swift/utils/build-script", line 673, in main_normal
    invocation.execute()
  File "/home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2/swift/utils/swift_build_support/swift_build_support/build_script_invocation.py", line 669, in execute
    self._execute(pipeline, all_host_names)
  File "/home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2/swift/utils/swift_build_support/swift_build_support/build_script_invocation.py", line 727, in _execute
    self.execute_product_build_steps(product_class, host_target)
  File "/home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2/swift/utils/swift_build_support/swift_build_support/build_script_invocation.py", line 783, in execute_product_build_steps
    product.build(host_target)
  File "/home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2/swift/utils/swift_build_support/swift_build_support/products/earlyswiftdriver.py", line 69, in build
    run_build_script_helper('build', host_target, self, self.args)
  File "/home/swm/workspace/debian/build/swiftlang/swiftlang_5.6.2/swift/utils/swift_build_support/swift_build_support/products/earlyswiftdriver.py", line 107, in run_build_script_helper
    swiftc_path = os.path.abspath(product.toolchain.swiftc)
  File "/usr/lib/python3.10/posixpath.py", line 378, in abspath
    path = os.fspath(path)
TypeError: expected str, bytes or os.PathLike object, not NoneType
ERROR: command terminated with a non-zero exit status 1, aborting

I'm not likely to be doing any debug or pull requests on this any time soon as I'm focused on packaging.

tachoknight · 2022-08-31T21:12:28Z

I had a similar issue with Swift being installed while packaging, but that was a mistake on my part (testing one version while building another) and the Fedora builders[1] won't have Swift installed by default.

[1] Dunno how Debian works, but all packages in the Fedora/RHEL environment are built from source on Fedora-controlled hardware, essentially in a special spun-up container; if I don't include it in the %BuildRequires section, it won't be in the container (which was how I discovered building Swift requires rsync 🙃).

melizasw · 2022-08-31T21:27:48Z

Yes, it is the same with Debian. I should be using chroot and a clean build environment each time, but I'm not there yet. There is pretty much no chance that the official Debian package would ever get built with that other "swift" package installed. I have rsync in my build dependencies as well, not because I discovered that on my own, but from benefiting from your work. :-)

I've still got some things to sort out, but I'm going to ask if what I have now is good enough to upload to Debian as a starting point.

tachoknight · 2022-08-31T21:32:53Z

out of curiosity, and because I don't have a Debian box handy, what is the other swift program? In Fedora's case there is another swift, but it's part of the OpenStack Object Storage API Python library, so the chance of a conflict with Swift® is effectively nil.

melizasw · 2022-08-31T21:41:54Z

On Debian/Ubuntu/Pop_OS there is another package "swift" but it doesn't actually provide the binary /usr/bin/swift, that is provided by the related python-swiftclient and they are indeed part of the OpenStack Object Storage API Python library.

$ sudo nala install python3-swiftclient
$ which swift
/usr/bin/swift
$ swift --version
python-swiftclient 3.13.1

I'd prefer to have swiftlang refuse to install if python3-swiftclient is installed, but Debian policy prohibits two packages from providing the same binary unless they are are the same program having different implementations. I could ask for an exception to this policy, but I think prompting to make the link works too.

tachoknight · 2022-08-31T21:46:07Z

Not sure if I got the reviewer on a good day, but I basically said that there is practically zero chance of conflict, given the usage domains were so wildly different; a system using OpenStack Storage is unlikely to also be a developer's machine wanting to use a cool programming language.

finagolfin · 2022-08-31T22:26:28Z

Here is the log file from trying to build Swift 5.6.2 when Swift is not installed but /usr/bin/swift is some other binary than Swift (copied from /usr/bin/ls in this case)

It looks like it's reporting correctly that there's no swiftc, though the error is a bit weird. It has nothing to do with the fake swift binary you added.

melizasw · 2022-08-31T22:29:14Z

It looks like it's reporting correctly that there's no swiftc, though the error is a bit weird. It has nothing to do with the fake swift binary you added.

And yet I can repeatedly turn this error on and off by copying a binary to /usr/bin/swift or deleting it.

melizasw · 2022-08-31T22:52:37Z

Not sure if I got the reviewer on a good day, but I basically said that there is practically zero chance of conflict, given the usage domains were so wildly different; a system using OpenStack Storage is unlikely to also be a developer's machine wanting to use a cool programming language.

Good to know. I've asked my package sponsor how best to handle this and mentioned this as being what Fedora has done. I think the only issue would be not having separate runtime libraries and needing to install swiftlang to get them. Have you done any work on exploring separating out the runtime libraries into their own package?

finagolfin · 2022-09-01T05:06:34Z

And yet I can repeatedly turn this error on and off by copying a binary to /usr/bin/swift or deleting it.

Ah, you're right, found it. The current build checks for both swift and swiftc and tries to build the early swift driver if it finds just the former, as it assumes both will be installed together. Obviously, that assumption will break if your other OpenStack package is installed instead. I wouldn't worry about this, as very few will likely build the Swift toolchain, and almost nobody will do it with that other Swift package installed.

melizasw · 2022-09-01T15:50:56Z

@tachoknight my Debian sponsor has asked me to move from the Swift provided clang, llvm, cmake, and icu packages to those that come with Debian. I know that lldb is customized by Swift as mentioned in your blog post, but what of these others? I'm assuming that icu and cmake would be fine as long as Swift doesn't depend on a specific version's features.

Do you know and/or do you have a blog post about that sort of issues that I can point him to? He is one of the Debian LLVM package maintainers so he is very experienced in this area.

Of course anyone else that knows is welcome to chime in too.

tachoknight · 2022-09-01T16:09:38Z

This was my experience as well. The Swift-provided version of LLVM/LLDB is custom for Swift; the standard LLVM/LLDB you might install on any Debian or Fedora box knows nothing about Swift and it simply won't work. The solution I use in Fedora is to hide everything in /usr/libexec/swift and just symlink swift and swiftc to /usr/bin; the custom lldb executable for Swift is not on the path so there's no collision with an existing LLVM/LLDB installation.

Two things I can remember too: When I was originally getting it working with Fedora, I discovered that a lot of of the code assumes executables are in the same directory, or if dynamically loading a library, it will explicitly say something like ../lib/libFoo.so or whatever. The Swift toolchain is a complete package unto itself and thus it really needs to stay together; many early bugs with Swift on Fedora was simply due to constantly missing a spot where I had tried to redirect the loader to a more general location (e.g. Fedora wants all its 64-bit libs in /usr/lib64) and it was really frustrating. Thus when I was able to just drop everything into /usr/libexec/swift, it made life so much easier, and so many patches (and related bugs) just magically went away.
The other thing that has come up, and I want to say it's somewhere on the Swift forums, that there was some discussion about moving Swift upstream to be part of the LLVM project. I have no idea what, if any, plans there are to do that and there's no point in thinking about it (this is to head off the possibility of someone asking "Why don't they just move everything to the LLVM project?").

melizasw · 2022-09-01T16:18:20Z

Thanks @tachoknight, I have forwarded your reply to my sponsor in the hopes that we will agree to keeping Swift together until upstream makes it possible for us to more easily split it apart.

finagolfin · 2022-09-01T16:49:06Z

As for CMake and ICU, the Swift build just uses the upstream source for each of those, so no problem with not building those from source and using the prebuilt Debian packages instead, provided they're not really old.

The only issue is that if you use the system ICU, you may have to bump the Foundation build everytime the system ICU is updated, to make sure it's linked against the latest version, whereas you don't need to do that if you build another libicu for Swift and stash it separately with the Swift-forked lldb and so on.

finagolfin · 2022-09-01T16:53:00Z

there was some discussion about moving Swift upstream to be part of the LLVM project.

Not Swift, I believe they just want to slowly upstream all Swift changes from their forked LLVM/clang/lldb to the upstream LLVM repo and get rid of those LLVM forks one day, but I'm guessing that's probably years away.

tachoknight · 2022-09-01T16:54:46Z

Ah, that's right, I was remembering it incorrectly.

melizasw · 2022-09-01T17:06:50Z

Thank you all for the information and help. My sponsor would like me to move to as many Debian packages as possible so here is our plan:

Switch to Debian cmake and ninja (Debian ftpmasters will reject this package otherwise)
Release swiftlang to Debian Experimental
Switch to Debian icu, llvm, and clang
Release to Debian Testing (from here it migrates to unstable after 5 days then to stable releases and derivative distributions)

tachoknight · 2022-09-01T17:09:11Z

Out of curiosity, what does it mean to switch to the Debian llvm and clang?

melizasw · 2022-09-01T17:15:33Z

Out of curiosity, what does it mean to switch to the Debian llvm and clang?

I'm hoping that will be open for negotiation. The desire is to not be packaging yet another fork of llvm/lldb/clang and having to deal with its bugs, but how do I make use of a tool chain that doesn't support my language? Start submitting all of Swift's changes as pull requests to Debian's LLVM packages? At that point it seems like you're still having to maintain a fork, but now those bugs impact far more Debian users than just the swiflang users. In any case, I must at least give it the old college try.

yuzibo · 2024-11-04T08:47:39Z

@melizasw Many thanks for your sharing about this, I will try it on my side.

BTW, do you need one real riscv64 hardware to debug something on here? if so, I can offer you with access remote with ssh.

yuzibo · 2024-11-04T15:21:12Z

@melizasw It moved forward a lot with your patch. now it failed with the below:

public/CMakeFiles/swiftDemangling-linux-riscv64.dir/__/__/lib/Demangling/Errors.cpp.o.d -o stdlib/public/CMakeFiles/swiftDemangling-linux
-riscv64.dir/__/__/lib/Demangling/Errors.cpp.o -c /<<PKGBUILDDIR>>/swift/lib/Demangling/Errors.cpp
In file included from /<<PKGBUILDDIR>>/swift/lib/Demangling/Errors.cpp:19:
In file included from /<<PKGBUILDDIR>>/swift/include/swift/Demangling/Errors.h:24:
In file included from /<<PKGBUILDDIR>>/build/buildbot_linux/llvm-linux-riscv64/lib/clang/13.0.0/include/inttypes.h:21:
In file included from /usr/include/inttypes.h:25:
In file included from /usr/include/features.h:402:
/usr/include/features-time64.h:20:10: fatal error: 'bits/wordsize.h' file not found
#include <bits/wordsize.h>
         ^~~~~~~~~~~~~~~~~
1 error generated.
[48/1463][  3%][2.057s] Copying Target.h to /<<PKGBUILDDIR>>/build/buildbot_linux/swift-linux-riscv64/./lib/swift/shims
[49/1463][  3%][2.058s] Copying UnicodeData.h to /<<PKGBUILDDIR>>/build/buildbot_linux/swift-linux-riscv64/./lib/swift/shims
[50/1463][  3%][2.059s] Copying ThreadLocalStorage.h to /<<PKGBUILDDIR>>/build/buildbot_linux/swift-linux-riscv64/./lib/swift/shims
[51/1463][  3%][2.170s] Copying module.modulemap to /<<PKGBUILDDIR>>/build/buildbot_linux/swift-linux-riscv64/./lib/swift/shims
...

It seems it has finished the first stage of building. I am looking at link you gave me above.

melizasw · 2024-11-04T15:48:36Z

Yes, I am getting the same error now. It can't seem to locate /usr/include/riscv64-linux-gnu/bits/wordsize.h even though it has no problem doing so on x86_64 and arm64. I will try to dig into this tonight after work. This is the same error that I got on 5.7.3 that stopped me and I did not get past. My best guess is an issue configuring include paths in the CMake files.

tachoknight · 2024-11-05T21:33:22Z

I was doing well building 5.8.1 when Debian switched to Clang 19 which introduced -Wcast-function-type-mismatch and then enabled it by default. This has caused an error building swift-corelibs-libdispatch which I have reported on github in case they wish to fix it. For now I'd just like to add -Wno-cast-function-type-mismatch to the flags for swift-corelibs-libdispatch to turn off the warning/error. Can someone point me in the right direction to inject this flag into the swift build scripts?

I added this to my build script and it works now:

export CFLAGS="-Wno-error=cast-function-type `echo $CFLAGS`"

tachoknight · 2024-11-16T15:43:31Z

@melizasw It turned out to be a little bit more difficult than what I initially wrote. Here's the patch file I addd to make it work reliably. Hopefully that helps. :)

melizasw · 2024-11-17T02:59:49Z

@melizasw It turned out to be a little bit more difficult than what I initially wrote. Here's the patch file I addd to make it work reliably. Hopefully that helps. :)

Yah, I ended up using this patch:

--- swiftlang-5.8.1.orig/swift-corelibs-libdispatch/cmake/modules/DispatchCompilerWarnings.cmake
+++ swiftlang-5.8.1/swift-corelibs-libdispatch/cmake/modules/DispatchCompilerWarnings.cmake
@@ -65,6 +65,7 @@ else()
   add_compile_options($<$<OR:$<COMPILE_LANGUAGE:C>,$<COMPILE_LANGUAGE:CXX>>:-Wno-used-but-marked-unused>)
   add_compile_options($<$<OR:$<COMPILE_LANGUAGE:C>,$<COMPILE_LANGUAGE:CXX>>:-Wno-void-pointer-to-int-cast>)
   add_compile_options($<$<OR:$<COMPILE_LANGUAGE:C>,$<COMPILE_LANGUAGE:CXX>>:-Wno-vla>)
+  add_compile_options($<$<OR:$<COMPILE_LANGUAGE:C>,$<COMPILE_LANGUAGE:CXX>>:-Wno-error=cast-function-type-mismatch>)
 
   if(CMAKE_SYSTEM_NAME STREQUAL Android)
     add_compile_options($<$<OR:$<COMPILE_LANGUAGE:C>,$<COMPILE_LANGUAGE:CXX>>:-Wno-incompatible-function-pointer-types>)

The issue now is that 5.8.1 builds fine on amd64, but fail with a stack dump on arm64 with Clang 18 and 19. I'm a little stumped, but haven't spent a lot of time on it yet. Might be related to #70345

[1418/1463][ 96%][5364.842s] Compiling /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/stdlib/private/StdlibUnittest//LINUX/aarch64/StdlibUnittest.o
FAILED: stdlib/private/StdlibUnittest/LINUX/aarch64/StdlibUnittest.o /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/stdlib/private/StdlibUnittest/LINUX/aarch64/StdlibUnittest.o 
cd /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/stdlib/private/StdlibUnittest && /usr/bin/cmake -E env LD_LIBRARY_PATH=/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bootstrapping1/lib/swift/linux /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/binforpython/python /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/swift/utils/line-directive @/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/stdlib/private/StdlibUnittest/20a38dcb7fd74f7c606e850bcb913edec34a43c2.txt -- /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/./bin/swiftc -c -sdk / -target aarch64-unknown-linux-gnu -resource-dir /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/./lib/swift -O -D SWIFT_ENABLE_EXPERIMENTAL_CONCURRENCY -D SWIFT_ENABLE_EXPERIMENTAL_DISTRIBUTED -D SWIFT_ENABLE_EXPERIMENTAL_DIFFERENTIABLE_PROGRAMMING -D SWIFT_ENABLE_EXPERIMENTAL_STRING_PROCESSING -D SWIFT_RUNTIME_OS_VERSIONING -D SWIFT_STDLIB_ENABLE_UNICODE_DATA -D SWIFT_STDLIB_ENABLE_VECTOR_TYPES -D SWIFT_STDLIB_HAS_COMMANDLINE -D SWIFT_STDLIB_HAS_STDIN -D SWIFT_STDLIB_HAS_ENVIRON -Xcc -DSWIFT_STDLIB_HAS_ENVIRON -D SWIFT_THREADING_LINUX -tools-directory /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/llvm-linux-aarch64/./bin -module-cache-path /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/./module-cache -no-link-objc-runtime -enable-library-evolution -library-level api -Xfrontend -require-explicit-availability=ignore -Xfrontend -enforce-exclusivity=unchecked -D SWIFT_ENABLE_REFLECTION -module-name StdlibUnittest -swift-version 5 -runtime-compatibility-version none -disable-autolinking-runtime-compatibility-dynamic-replacements -Xfrontend -disable-autolinking-runtime-compatibility-concurrency -Xfrontend -disable-objc-interop -Xfrontend -disable-objc-attr-requires-foundation-module -DSWIFT_ENABLE_REFLECTION -warn-implicit-overrides -Xfrontend -enable-ossa-modules -Xfrontend -enable-lexical-lifetimes=false -Xfrontend -disable-implicit-concurrency-module-import -Xfrontend -disable-implicit-string-processing-module-import -Xfrontend -disable-implicit-string-processing-module-import -Xfrontend -prespecialize-generic-metadata -Xfrontend -define-availability -Xfrontend SwiftStdlib\ 9999:macOS\ 9999,\ iOS\ 9999,\ watchOS\ 9999,\ tvOS\ 9999 -Xfrontend -define-availability -Xfrontend SwiftStdlib\ 5.0:macOS\ 10.14.4,\ iOS\ 12.2,\ watchOS\ 5.2,\ tvOS\ 12.2 -Xfrontend -define-availability -Xfrontend SwiftStdlib\ 5.1:macOS\ 10.15,\ iOS\ 13.0,\ watchOS\ 6.0,\ tvOS\ 13.0 -Xfrontend -define-availability -Xfrontend SwiftStdlib\ 5.2:macOS\ 10.15.4,\ iOS\ 13.4,\ watchOS\ 6.2,\ tvOS\ 13.4 -Xfrontend -define-availability -Xfrontend SwiftStdlib\ 5.3:macOS\ 11.0,\ iOS\ 14.0,\ watchOS\ 7.0,\ tvOS\ 14.0 -Xfrontend -define-availability -Xfrontend SwiftStdlib\ 5.4:macOS\ 11.3,\ iOS\ 14.5,\ watchOS\ 7.4,\ tvOS\ 14.5 -Xfrontend -define-availability -Xfrontend SwiftStdlib\ 5.5:macOS\ 12.0,\ iOS\ 15.0,\ watchOS\ 8.0,\ tvOS\ 15.0 -Xfrontend -define-availability -Xfrontend SwiftStdlib\ 5.6:macOS\ 12.3,\ iOS\ 15.4,\ watchOS\ 8.5,\ tvOS\ 15.4 -Xfrontend -define-availability -Xfrontend SwiftStdlib\ 5.7:macOS\ 13.0,\ iOS\ 16.0,\ watchOS\ 9.0,\ tvOS\ 16.0 -Xfrontend -define-availability -Xfrontend SwiftStdlib\ 5.8:macOS\ 13.3,\ iOS\ 16.4,\ watchOS\ 9.4,\ tvOS\ 16.4 -Xfrontend -define-availability -Xfrontend SwiftStdlib\ 5.9:macOS\ 9999,\ iOS\ 9999,\ watchOS\ 9999,\ tvOS\ 9999 -Xfrontend -target-min-inlining-version -Xfrontend min -module-link-name swiftStdlibUnittest -whole-module-optimization -parse-as-library -resource-dir /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/./lib/swift -I /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/./lib/swift/linux -o /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/stdlib/private/StdlibUnittest//LINUX/aarch64/StdlibUnittest.o @/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/stdlib/private/StdlibUnittest/20a38dcb7fd74f7c606e850bcb913edec34a43c2.txt
swift-frontend: /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/llvm-project/llvm/include/llvm/ADT/DenseMap.h:410: void llvm::DenseMapBase<llvm::DenseMap<swift::irgen::LinkEntity, llvm::Function *>, 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: /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend -frontend -c /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/swift/stdlib/private/StdlibUnittest/StdlibUnittest.swift /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/swift/stdlib/private/StdlibUnittest/CheckStrideable.swift /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/swift/stdlib/private/StdlibUnittest/InspectValue.swift /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/swift/stdlib/private/StdlibUnittest/LifetimeTracked.swift /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/swift/stdlib/private/StdlibUnittest/MinimalTypes.swift /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/swift/stdlib/private/StdlibUnittest/OpaqueIdentityFunctions.swift /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/swift/stdlib/private/StdlibUnittest/RaceTest.swift /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/swift/stdlib/private/StdlibUnittest/Statistics.swift /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/swift/stdlib/private/StdlibUnittest/StdlibCoreExtras.swift /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/swift/stdlib/private/StdlibUnittest/StringConvertible.swift /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/swift/stdlib/private/StdlibUnittest/StringTestHelpers.swift /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/swift/stdlib/private/StdlibUnittest/TestHelpers.swift /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/swift/stdlib/private/StdlibUnittest/TypeIndexed.swift -supplementary-output-file-map /tmp/supplementaryOutputs-1fc52d -target aarch64-unknown-linux-gnu -Xllvm -aarch64-use-tbi -disable-objc-interop -sdk / -I /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/./lib/swift/linux -warn-implicit-overrides -enable-library-evolution -module-cache-path /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/./module-cache -module-link-name swiftStdlibUnittest -resource-dir /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/./lib/swift -swift-version 5 -tools-directory /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/llvm-linux-aarch64/./bin -O -library-level api -D SWIFT_ENABLE_EXPERIMENTAL_CONCURRENCY -D SWIFT_ENABLE_EXPERIMENTAL_DISTRIBUTED -D SWIFT_ENABLE_EXPERIMENTAL_DIFFERENTIABLE_PROGRAMMING -D SWIFT_ENABLE_EXPERIMENTAL_STRING_PROCESSING -D SWIFT_RUNTIME_OS_VERSIONING -D SWIFT_STDLIB_ENABLE_UNICODE_DATA -D SWIFT_STDLIB_ENABLE_VECTOR_TYPES -D SWIFT_STDLIB_HAS_COMMANDLINE -D SWIFT_STDLIB_HAS_STDIN -D SWIFT_STDLIB_HAS_ENVIRON -D SWIFT_THREADING_LINUX -D SWIFT_ENABLE_REFLECTION -D SWIFT_ENABLE_REFLECTION -require-explicit-availability=ignore -enforce-exclusivity=unchecked -disable-autolinking-runtime-compatibility-concurrency -disable-objc-interop -disable-objc-attr-requires-foundation-module -enable-ossa-modules -enable-lexical-lifetimes=false -disable-implicit-concurrency-module-import -disable-implicit-string-processing-module-import -disable-implicit-string-processing-module-import -prespecialize-generic-metadata -define-availability "SwiftStdlib 9999:macOS 9999, iOS 9999, watchOS 9999, tvOS 9999" -define-availability "SwiftStdlib 5.0:macOS 10.14.4, iOS 12.2, watchOS 5.2, tvOS 12.2" -define-availability "SwiftStdlib 5.1:macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0" -define-availability "SwiftStdlib 5.2:macOS 10.15.4, iOS 13.4, watchOS 6.2, tvOS 13.4" -define-availability "SwiftStdlib 5.3:macOS 11.0, iOS 14.0, watchOS 7.0, tvOS 14.0" -define-availability "SwiftStdlib 5.4:macOS 11.3, iOS 14.5, watchOS 7.4, tvOS 14.5" -define-availability "SwiftStdlib 5.5:macOS 12.0, iOS 15.0, watchOS 8.0, tvOS 15.0" -define-availability "SwiftStdlib 5.6:macOS 12.3, iOS 15.4, watchOS 8.5, tvOS 15.4" -define-availability "SwiftStdlib 5.7:macOS 13.0, iOS 16.0, watchOS 9.0, tvOS 16.0" -define-availability "SwiftStdlib 5.8:macOS 13.3, iOS 16.4, watchOS 9.4, tvOS 16.4" -define-availability "SwiftStdlib 5.9:macOS 9999, iOS 9999, watchOS 9999, tvOS 9999" -target-min-inlining-version min -Xcc -DSWIFT_STDLIB_HAS_ENVIRON -parse-as-library -module-name StdlibUnittest -o /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/stdlib/private/StdlibUnittest//LINUX/aarch64/StdlibUnittest.o -runtime-compatibility-version none -disable-autolinking-runtime-compatibility-dynamic-replacements
1.	Swift version 5.8.1 (swift-5.8.1-RELEASE)
2.	Compiling with the current language version
3.	While evaluating request IRGenRequest(IR Generation for module StdlibUnittest)
4.	While emitting prespecialized metadata for type 'Optional<Int>'
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x6570028) [0x5555f8b10028]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x656e06c) [0x5555f8b0e06c]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x6570450) [0x5555f8b10450]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0) [0x7fff002107b0]
/lib/aarch64-linux-gnu/libc.so.6(+0x87240) [0x7ffeff627240]
/lib/aarch64-linux-gnu/libc.so.6(gsignal+0x20) [0x7ffeff5d67a0]
/lib/aarch64-linux-gnu/libc.so.6(abort+0xf8) [0x7ffeff5c1a48]
/lib/aarch64-linux-gnu/libc.so.6(+0x2f860) [0x7ffeff5cf860]
/lib/aarch64-linux-gnu/libc.so.6(+0x2f8d4) [0x7ffeff5cf8d4]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x1190f38) [0x5555f3730f38]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x1190dc8) [0x5555f3730dc8]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x1190d14) [0x5555f3730d14]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x11888dc) [0x5555f37288dc]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x126a590) [0x5555f380a590]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x1269d68) [0x5555f3809d68]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x12699ac) [0x5555f38099ac]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x11f9628) [0x5555f3799628]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x1178f64) [0x5555f3718f64]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x1063738) [0x5555f3603738]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x10af384) [0x5555f364f384]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x107309c) [0x5555f361309c]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0x106463c) [0x5555f360463c]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0xd6ac54) [0x5555f330ac54]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0xd67028) [0x5555f3307028]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0xd66190) [0x5555f3306190]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0xd76f70) [0x5555f3316f70]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0xd687e0) [0x5555f33087e0]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0xd679f0) [0x5555f33079f0]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0xbdad64) [0x5555f317ad64]
/lib/aarch64-linux-gnu/libc.so.6(+0x2229c) [0x7ffeff5c229c]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x9c) [0x7ffeff5c237c]
/home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend(+0xbd9df0) [0x5555f3179df0]
<unknown>:0: error: unable to execute command: Aborted
<unknown>:0: error: compile command failed due to signal 6 (use -v to see invocation)
[1419/1463][ 96%][5365.217s] Compiling /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/stdlib/public/StringProcessing//LINUX/aarch64/_StringProcessing.o
FAILED: stdlib/public/StringProcessing/LINUX/aarch64/_StringProcessing.o /home/swm/workspace/debian/build/swiftlang/swiftlang-5.8.1/build/buildbot_linux/swift-linux-aarch64/stdlib/public/StringProcessing/LINUX/aarch64/_StringProcessing.o

melizasw · 2024-11-17T16:29:11Z

Confirmed that 5.8.1 build failures on Debian Sid with default Clang package (Clang 19) on Arm64 are fixed with the patch provided with bug report #70345

Assertion `!FoundVal && "Key already in new map?"' failed.

melizasw · 2024-11-18T15:24:00Z

I have 5.9.2 building fine on x86_64, but on aarch64:

clang: error: no such file or directory: '/usr/libexec/swift/lib/swift/linux/x86_64/swiftrt.o'

Sigh

ETA: Self-induced with a patch that hard coded that path.

melizasw · 2024-11-24T22:24:19Z

On to the next issue with packaging 5.9.2. It builds on x86_64 but not aarch64. I've traced it down to an error parsing json by swiftpm/Utilities/bootstrapping because switfc outputs some non-json on aarch64 that trips up the json parser.

x86_64:

usr/bin/swiftc -print-target-info
{
  "compilerVersion": "Swift version 5.9.2 (swift-5.9.2-RELEASE)",
  "target": {
    "triple": "x86_64-pc-linux-gnu",
    "unversionedTriple": "x86_64-pc-linux-gnu",
    "moduleTriple": "x86_64-pc-linux-gnu",
    "compatibilityLibraries": [ ],
    "librariesRequireRPath": false
  },
  "paths": {
    "runtimeLibraryPaths": [
      "/home/swm/workspace/debian/build/swiftlang/swiftlang-5.9.2/usr/lib/swift/linux"
    ],
    "runtimeLibraryImportPaths": [
      "/home/swm/workspace/debian/build/swiftlang/swiftlang-5.9.2/usr/lib/swift/linux",
      "/home/swm/workspace/debian/build/swiftlang/swiftlang-5.9.2/usr/lib/swift/linux/x86_64"
    ],
    "runtimeResourcePath": "/home/swm/workspace/debian/build/swiftlang/swiftlang-5.9.2/usr/lib/swift"

aarch64:

usr/bin/swiftc -print-target-info
swift runtime: unable to protect path to swift-backtrace at 0x7fff4c7e5000: 22; disabling backtracing.
swift runtime: unable to protect environment for swift-backtrace at 0x7fff4c7dd000: 22; disabling backtracing.
swift runtime: unable to protect path to swift-backtrace at 0x7fff56635000: 22; disabling backtracing.
swift runtime: unable to protect environment for swift-backtrace at 0x7fff5662d000: 22; disabling backtracing.
{
  "compilerVersion": "Swift version 5.9.2 (swift-5.9.2-RELEASE)",
  "target": {
    "triple": "aarch64-unknown-linux-gnu",
    "unversionedTriple": "aarch64-unknown-linux-gnu",
    "moduleTriple": "aarch64-unknown-linux-gnu",
    "compatibilityLibraries": [ ],
    "librariesRequireRPath": false
  },
  "paths": {
    "runtimeLibraryPaths": [
      "/home/swm/workspace/debian/build/swiftlang/swiftlang-5.9.2/usr/lib/swift/linux"
    ],
    "runtimeLibraryImportPaths": [
      "/home/swm/workspace/debian/build/swiftlang/swiftlang-5.9.2/usr/lib/swift/linux",
      "/home/swm/workspace/debian/build/swiftlang/swiftlang-5.9.2/usr/lib/swift/linux/aarch64"
    ],
    "runtimeResourcePath": "/home/swm/workspace/debian/build/swiftlang/swiftlang-5.9.2/usr/lib/swift"
  }
}

Swiftc 5.8.1 on aarch64 does not print this message. Does anyone have an idea on this one?
Maybe this? https://forums.swift.org/t/steps-to-resolve-unable-to-protect-swift-backtrace-disabling-backtracing/72076/2

melizasw · 2024-11-26T02:20:57Z

5.9.2 is now building on Arm after modifying swift/include/swift/Runtime/Config.h to match Debian's page sizes.

 /// What is the system page size?
-#if defined(__APPLE__) && defined(__arm64__)
+#if defined(__aarch64__)
   // Apple Silicon systems use a 16KB page size
   #define SWIFT_PAGE_SIZE 16384
 #else

melizasw · 2024-12-21T18:09:42Z

Just a happy little update.

With version 5.8.1 I was finally able to figure out why my builds always failed on Ubuntu. It turns out to have been a "known issue" for the Ubuntu folks where they include some GCC LTO flags by default, knowing that it will break a Clang build. So now Swift 5.8.1 is in Ubuntu Plucky and should be available to all Ubuntu derivatives.

Swift 5.9.2 is ready now and should be on its way into the repositories soon.

melizasw · 2025-01-07T05:40:10Z

Swift 5.9.2 made it into Debian unstable and out to Ubuntu Plucky. It should be replaced soon by 5.10.1 which leaves me with the exciting work of getting 6.0.3 ready for Debian.

The build of 6.0.3 goes quite far, but fails when building libFoundationEssentials.so from the new swift-foundation. This is the error:
error: unknown argument: '-Wl,-z,relro'

It is plainly obvious that these are linker arguments that one would pass to Clang, but instead they are being passed to swiftc:

swiftlang-6.0.3/build/buildbot_linux/swift-linux-x86_64/bin/swiftc -j 12 -num-threads 12 -emit-library -module-cache-path "swiftlang-6.0.3/build/buildbot_linux/foundation-linux-x86_64/module-cache" -O  -Wl,-z,relro  -Xlinker -soname -Xlinker libFoundationEssentials.so -o lib/libFoundationEssentials.so
... and so on

I've not yet figured out what is injecting these arguments, can anyone help me locate this?

Also, until now the Swift build has always chosen GNU ld for linking, but with 6.0.3 it now seemingly randomly switches between GNU ld and GNU gold. Should I add GNU gold as a build depends (it is not a build depends now) or stick with just GNU ld?

etcwilde · 2025-01-07T06:15:00Z

error: unknown argument: '-Wl,-z,relro'

This looks like something that might be coming in from CMake. I don't know whether it's a Debian patch to CMake, something that Foundation is doing that's only triggering on Debian, or something else.

Some places to look are in the build directory, CMakeFiles/rules.ninja, build.ninja, and then from the build directory running cmake . --trace-expand 2> config.log. Then inside of config.log, search for -Wl,-z,relro and see where it shows up. That should give us a hint about where it's coming from.

but with 6.0.3 it now seemingly randomly switches between GNU ld and GNU gold.

This is likely because we leave it up to the clang-linker to decide which one to use by default and it might be picking up different clang-linkers through the build because build-script is not terribly water-tight and changes things through the build. You can specify the linker that the toolchain will use by default by passing -DCLANG_DEFAULT_LINKER=<linker> to LLVM (see

swift/utils/build-presets.ini

Lines 925 to 927 in 57657c6

    
           llvm-cmake-options= 
        
             -DCROSS_TOOLCHAIN_FLAGS_LLVM_NATIVE='-DCMAKE_C_COMPILER=clang;-DCMAKE_CXX_COMPILER=clang++' 
        
             -DCLANG_DEFAULT_LINKER=gold

).
That said, there was some work done on the BFD linker that fixes the relocation bug, so new versions of the GNU BFD linker should work now.

finagolfin · 2025-01-27T19:59:20Z

Hey @melizasw, been awhile since I responded to this thread, as there was a problem with my github account a couple years ago, which appears to have removed this issue from my notifications back then.

I've not yet figured out what is injecting these arguments, can anyone help me locate this?

What version of CMake are you using? I reported a regression in CMake 3.30 to @etcwilde months ago- maybe he didn't see it or forgot- where it started passing CMAKE_SHARED_LINKER_FLAGS to the Swift compiler, which it didn't for CMake 3.29 and earlier. I work around it on my Android CI by resetting that CMake variable, you can try the same.

melizasw · 2025-03-17T03:59:45Z

What version of CMake are you using? swiftlang/swift-foundation#878 (comment) maybe he didn't see it or forgot- where it started passing CMAKE_SHARED_LINKER_FLAGS to the Swift compiler, which it didn't for CMake 3.29 and earlier. I work around it on my Android CI by resetting that CMake variable, you can try the same.

Debian has been on CMake 3.31 since late November. Your suggested fix did the trick, thanks for that.

So now I'm on to the next error. It seems to be a failed assertion when calling computeHostNumPhysicalCores() within llbuild/lib/llvm/Support/Host.cpp. Since this is a linux build this function is getting the core count from /proc/cpuinfo and putting it into a SmallVector which I assume uses a BitVector.

FAILED: lib/llvm/Support/CMakeFiles/llvmSupport.dir/Host.cpp.o
clang++: swiftlang-6.0.3/llvm-project/llvm/include/llvm/ADT/BitVector.h:358: BitVector &llvm::BitVector::set(unsigned int): Assertion `Idx < Size && "access in bound"' failed.

The file llbuild/lib/llvm/Support/Host.cpp appears to have not been touched in the last 6 years so there must have been a change elsewhere that has triggered this.

finagolfin · 2025-03-17T10:11:20Z

Can you paste the whole error? This seems like an assertion in the freshly-built Swift-forked clang itself, not anything in llbuild.

melizasw · 2025-03-17T13:51:28Z

Yes, please let me know if you want me to provide more of the earlier part of the log file or the files in /tmp that it references.

[25/150][ 16%][4.455s] Building CXX object lib/llvm/Support/CMakeFiles/llvmSupport.dir/Host.cpp.o
FAILED: lib/llvm/Support/CMakeFiles/llvmSupport.dir/Host.cpp.o 
/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang++  -I/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/llbuild/include -g -O2 -ffile-prefix-map=/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O3 -DNDEBUG -std=c++14 -fPIC -fno-rtti -fno-exceptions -Wbool-conversion -Wconstant-conversion -Wdeprecated-declarations -Wdocumentation -Wempty-body -Wenum-conversion -Wimplicit-fallthrough -Wint-conversion -Winvalid-offsetof -Wmost -Wnewline-eof -Wnon-virtual-dtor -Woverloaded-virtual -Wparentheses -Wsign-compare -Wswitch -Wuninitialized -Wunused-function -Wunused-value -Wunused-variable -include /home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/llbuild/include/libstdc++14-workaround.h -Wunreachable-code -UNDEBUG -MD -MT lib/llvm/Support/CMakeFiles/llvmSupport.dir/Host.cpp.o -MF lib/llvm/Support/CMakeFiles/llvmSupport.dir/Host.cpp.o.d -o lib/llvm/Support/CMakeFiles/llvmSupport.dir/Host.cpp.o -c /home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/llbuild/lib/llvm/Support/Host.cpp
dbg.assign not in same function as inst
  call void @llvm.dbg.assign(metadata i32 0, metadata !11652, metadata !DIExpression(DW_OP_LLVM_fragment, 64, 32), metadata !8668, metadata ptr %Size.i.i.i.i.i, metadata !DIExpression()), !dbg !11653
  store i32 0, ptr %Size.i.i.i.i.i222, align 8, !dbg !8667, !tbaa !6805, !DIAssignID !8668
dbg.assign not in same function as inst
  call void @llvm.dbg.assign(metadata i32 8, metadata !11652, metadata !DIExpression(DW_OP_LLVM_fragment, 96, 32), metadata !8670, metadata ptr %Capacity2.i.i.i.i.i, metadata !DIExpression()), !dbg !11653
  store i32 8, ptr %Capacity2.i.i.i.i.i223, align 4, !dbg !8669, !tbaa !6808, !DIAssignID !8670
dbg.assign not in same function as inst
  call void @llvm.dbg.assign(metadata i32 0, metadata !11647, metadata !DIExpression(DW_OP_LLVM_fragment, 64, 32), metadata !8664, metadata ptr %Size.i.i.i.i.i, metadata !DIExpression()), !dbg !11648
  store i32 0, ptr %Size.i.i.i.i.i222, align 8, !dbg !8663, !tbaa !6805, !DIAssignID !8664
dbg.assign not in same function as inst
  call void @llvm.dbg.assign(metadata i32 8, metadata !11647, metadata !DIExpression(DW_OP_LLVM_fragment, 96, 32), metadata !8666, metadata ptr %Capacity2.i.i.i.i.i, metadata !DIExpression()), !dbg !11648
  store i32 8, ptr %Capacity2.i.i.i.i.i223, align 4, !dbg !8665, !tbaa !6808, !DIAssignID !8666
clang++: /home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/llvm-project/llvm/include/llvm/ADT/BitVector.h:358: BitVector &llvm::BitVector::set(unsigned int): **Assertion `Idx < Size && "access in bound"' failed.**
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: /home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang++ -I/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/llbuild/include -g -O2 -ffile-prefix-map=/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O3 -DNDEBUG -std=c++14 -fPIC -fno-rtti -fno-exceptions -Wbool-conversion -Wconstant-conversion -Wdeprecated-declarations -Wdocumentation -Wempty-body -Wenum-conversion -Wimplicit-fallthrough -Wint-conversion -Winvalid-offsetof -Wmost -Wnewline-eof -Wnon-virtual-dtor -Woverloaded-virtual -Wparentheses -Wsign-compare -Wswitch -Wuninitialized -Wunused-function -Wunused-value -Wunused-variable -include /home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/llbuild/include/libstdc++14-workaround.h -Wunreachable-code -UNDEBUG -MD -MT lib/llvm/Support/CMakeFiles/llvmSupport.dir/Host.cpp.o -MF lib/llvm/Support/CMakeFiles/llvmSupport.dir/Host.cpp.o.d -o lib/llvm/Support/CMakeFiles/llvmSupport.dir/Host.cpp.o -c /home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/llbuild/lib/llvm/Support/Host.cpp
1.	<eof> parser at end of file
2.	Code generation
3.	Running pass 'Function Pass Manager' on module '/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/llbuild/lib/llvm/Support/Host.cpp'.
4.	Running pass 'Assignment Tracking Analysis' on function '@_ZL27computeHostNumPhysicalCoresv'
 #0 0x00005563c515f398 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x2af8398)
 #1 0x00005563c515d0ae llvm::sys::RunSignalHandlers() (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x2af60ae)
 #2 0x00005563c50cfd16 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
 #3 0x00007fe9e4649db0 (/lib/x86_64-linux-gnu/libc.so.6+0x3fdb0)
 #4 0x00007fe9e469e8ac __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #5 0x00007fe9e4649c82 raise ./signal/../sysdeps/posix/raise.c:27:6
 #6 0x00007fe9e46324ac abort ./stdlib/abort.c:81:3
 #7 0x00007fe9e4632420 __assert_perror_fail ./assert/assert-perr.c:31:1
 #8 0x00005563c4b22a91 (anonymous namespace)::AssignmentTrackingLowering::addMemDef((anonymous namespace)::AssignmentTrackingLowering::BlockInfo*, llvm::VariableID, (anonymous namespace)::AssignmentTrackingLowering::Assignment const&) AssignmentTrackingAnalysis.cpp:0:0
 #9 0x00005563c4b1ca75 (anonymous namespace)::AssignmentTrackingLowering::process(llvm::BasicBlock&, (anonymous namespace)::AssignmentTrackingLowering::BlockInfo*) AssignmentTrackingAnalysis.cpp:0:0
#10 0x00005563c4b1123f (anonymous namespace)::AssignmentTrackingLowering::run(FunctionVarLocsBuilder*) AssignmentTrackingAnalysis.cpp:0:0
#11 0x00005563c4b080f1 analyzeFunction(llvm::Function&, llvm::DataLayout const&, FunctionVarLocsBuilder*) AssignmentTrackingAnalysis.cpp:0:0
#12 0x00005563c4b07af0 llvm::AssignmentTrackingAnalysis::runOnFunction(llvm::Function&) (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x24a0af0)
#13 0x00005563c4c7ff97 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x2618f97)
#14 0x00005563c4c885f2 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x26215f2)
#15 0x00005563c4c80aa7 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x2619aa7)
#16 0x00005563c534c816 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, clang::CASOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>) (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x2ce5816)
#17 0x00005563c619d097 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x3b36097)
#18 0x00005563c728ac16 clang::ParseAST(clang::Sema&, bool, bool) (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x4c23c16)
#19 0x00005563c5b17f4f clang::FrontendAction::Execute() (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x34b0f4f)
#20 0x00005563c5a7ef53 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x3417f53)
#21 0x00005563c5bea85c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x358385c)
#22 0x00005563c35d7296 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0xf70296)
#23 0x00005563c35d0d41 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) driver.cpp:0:0
#24 0x00005563c58f98c9 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const::$_0>(long) Job.cpp:0:0
#25 0x00005563c50cfa5e llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x2a68a5e)
#26 0x00005563c58f8fa3 clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x3291fa3)
#27 0x00005563c58bc376 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x3255376)
#28 0x00005563c58bc637 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x3255637)
#29 0x00005563c58d99fa clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0x32729fa)
#30 0x00005563c35d01ac clang_main(int, char**, llvm::ToolContext const&) (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0xf691ac)
#31 0x00005563c35f0051 main (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0xf89051)
#32 0x00007fe9e4633ca8 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
#33 0x00007fe9e4633d65 call_init ./csu/../csu/libc-start.c:128:20
#34 0x00007fe9e4633d65 __libc_start_main ./csu/../csu/libc-start.c:347:5
#35 0x00005563c35ce101 _start (/home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin/clang+++0xf67101)
clang++: error: clang frontend command failed with exit code 134 (use -v to see invocation)
clang version 17.0.0
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/llvm-linux-x86_64/bin
clang++: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang++: note: diagnostic msg: /tmp/Host-1ff45e.cpp
clang++: note: diagnostic msg: /tmp/Host-1ff45e.sh
clang++: note: diagnostic msg: 

********************

finagolfin · 2025-03-17T14:40:46Z

Hmm, somebody reported the same error with the Swift-forked clang 10 months ago, swiftlang/llvm-project#8741, which they say led to cherry-picking swiftlang/llvm-project@91d7ca904 into the Swift fork.

I see that it only made it into the upcoming Swift 6.1 though, not Swift 6.0, so try applying that patch to your 6.0 build and see if it fixes this issue.

I'm not sure why the official Swift CI doesn't hit this also, may be related to it still building the Swift-forked clang in the current Swift 6 branches with the older clang in Swift 5.9, swiftlang/swift-docker#368, or some even older system clang? Maybe something in the host clang triggers this bug in the Swift-forked clang somehow. 🤷‍♂

melizasw · 2025-03-18T06:58:01Z

Yes, that did the trick. Now I'm on to the next error. Apparently I didn't grab swift-testing when I was assembling my source tarball. I'll have to fix that tomorrow.

I don't know how you managed to find that bug report and fix. I tried to search for similar error messages and wasn't getting anywhere. The help is much appreciated. Running into bugs like this when building for Debian seems to be par for the course. Not sure why.

finagolfin · 2025-03-18T08:24:07Z

I don't know how you managed to find that bug report and fix. I tried to search for similar error messages and wasn't getting anywhere.

Once I saw it was a clang error, I ran this search using the analysis pass from your error in that repo for the Swift-forked LLVM and that single issue came up. 😃

Running into bugs like this when building for Debian seems to be par for the course. Not sure why.

It's not just Debian, the Fedora build and others have reported similar issues, as the Swift toolchain build doesn't seem very robust on these non-Darwin platforms. Perhaps that's because the uptake outside macOS is still low- compare it to Rust- which will only change once more people are building it in more settings.

melizasw · 2025-03-19T05:28:03Z

Ok, I guess I was going after the wrong string in the error message and was blaming llbuild and not llvm so I was searching the wrong bug reports.

I'm now on what I hope will be the final build error - my old friend the architecture triple. You see, Swift takes the approach that everything Linux is {arch}-unknown-linux-gnu. Debian agrees with this on aarch64, but on x86_64 the vendor string is "pc" instead of "unknown". The new error appears to be caused by utils/swift_build_support/swift_build_support/products/product.py

    def get_linux_target_components(self, arch):
        # Map tuples of (platform, arch) to ABI
        #
        # E.x.: Hard ABI or Soft ABI for Linux map to gnueabihf
        arch_platform_to_abi = {
            # For now always map to hard float ABI.
            'armv7': ('arm', 'gnueabihf')
        }

        abi = 'gnu'
        vendor = 'unknown'

        try:
            output = shell.capture([self.toolchain.cc, "--print-target-triple"])

            # clang can't handle default `*-unknown-linux-*` components on Alpine,
            # it needs special handling to propagate `vendor` and `abi` intact
            if 'alpine-linux-musl' in output:
                vendor = 'alpine'
                abi = 'musl'

            sysroot_arch, abi = arch_platform_to_abi.get(arch, (arch, abi))

        except BaseException:
            # Default is just arch, gnu
            sysroot_arch, abi = arch_platform_to_abi.get(arch, (arch, abi))
        return sysroot_arch, vendor, abi

I'll find out in a few hours if my patch to set the vendor string works or not. I've also kicked off a build on my Pi5 as it shouldn't be hampered by this bug.

melizasw · 2025-03-19T07:05:28Z

Yes, that fixed that issue, but it wasn't the last one. At least I have a good idea where to look.

[6/6][100%][10.166s] Linking Swift shared library lib/libTesting.so
FAILED: lib/libTesting.so 
: && /home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/usr/bin/swiftc -target x86_64-pc-linux-gnu -j 12 -num-threads 12 -emit-library -O -swift-version 6  -Wl,-z,relro  -Xlinker -soname -Xlinker libTesting.so -o lib/libTesting.so Sources/Testing/CMakeFiles/Testing.dir/ABI/EntryPoints/ABIEntryPoint.swift.o Sources/Testing/CMakeFiles/Testing.dir/ABI/EntryPoints/EntryPoint.swift.o Sources/Testing/CMakeFiles/Testing.dir/ABI/EntryPoints/SwiftPMEntryPoint.swift.o Sources/Testing/CMakeFiles/Testing.dir/ABI/v0/ABIv0.Record.swift.o Sources/Testing/CMakeFiles/Testing.dir/ABI/v0/ABIv0.Record+Streaming.swift.o Sources/Testing/CMakeFiles/Testing.dir/ABI/v0/ABIv0.swift.o Sources/Testing/CMakeFiles/Testing.dir/ABI/v0/Encoded/ABIv0.EncodedEvent.swift.o Sources/Testing/CMakeFiles/Testing.dir/ABI/v0/Encoded/ABIv0.EncodedInstant.swift.o Sources/Testing/CMakeFiles/Testing.dir/ABI/v0/Encoded/ABIv0.EncodedIssue.swift.o Sources/Testing/CMakeFiles/Testing.dir/ABI/v0/Encoded/ABIv0.EncodedMessage.swift.o Sources/Testing/CMakeFiles/Testing.dir/ABI/v0/Encoded/ABIv0.EncodedTest.swift.o Sources/Testing/CMakeFiles/Testing.dir/Events/Clock.swift.o Sources/Testing/CMakeFiles/Testing.dir/Events/Event.swift.o Sources/Testing/CMakeFiles/Testing.dir/Events/Recorder/Event.ConsoleOutputRecorder.swift.o Sources/Testing/CMakeFiles/Testing.dir/Events/Recorder/Event.HumanReadableOutputRecorder.swift.o Sources/Testing/CMakeFiles/Testing.dir/Events/Recorder/Event.JUnitXMLRecorder.swift.o Sources/Testing/CMakeFiles/Testing.dir/Events/Recorder/Event.Symbol.swift.o Sources/Testing/CMakeFiles/Testing.dir/Events/TimeValue.swift.o Sources/Testing/CMakeFiles/Testing.dir/ExitTests/ExitCondition.swift.o Sources/Testing/CMakeFiles/Testing.dir/ExitTests/ExitTest.swift.o Sources/Testing/CMakeFiles/Testing.dir/ExitTests/WaitFor.swift.o Sources/Testing/CMakeFiles/Testing.dir/Expectations/Expectation.swift.o Sources/Testing/CMakeFiles/Testing.dir/Expectations/Expectation+Macro.swift.o Sources/Testing/CMakeFiles/Testing.dir/Expectations/ExpectationChecking+Macro.swift.o Sources/Testing/CMakeFiles/Testing.dir/Issues/Confirmation.swift.o Sources/Testing/CMakeFiles/Testing.dir/Issues/ErrorSnapshot.swift.o Sources/Testing/CMakeFiles/Testing.dir/Issues/Issue.swift.o Sources/Testing/CMakeFiles/Testing.dir/Issues/Issue+Recording.swift.o Sources/Testing/CMakeFiles/Testing.dir/Issues/KnownIssue.swift.o Sources/Testing/CMakeFiles/Testing.dir/Parameterization/CustomTestArgumentEncodable.swift.o Sources/Testing/CMakeFiles/Testing.dir/Parameterization/Test.Case.Generator.swift.o Sources/Testing/CMakeFiles/Testing.dir/Parameterization/Test.Case.ID.swift.o Sources/Testing/CMakeFiles/Testing.dir/Parameterization/Test.Case.swift.o Sources/Testing/CMakeFiles/Testing.dir/Parameterization/TypeInfo.swift.o Sources/Testing/CMakeFiles/Testing.dir/Running/Configuration.swift.o Sources/Testing/CMakeFiles/Testing.dir/Running/Configuration.TestFilter.swift.o Sources/Testing/CMakeFiles/Testing.dir/Running/Configuration+EventHandling.swift.o Sources/Testing/CMakeFiles/Testing.dir/Running/Runner.Plan.swift.o Sources/Testing/CMakeFiles/Testing.dir/Running/Runner.Plan+Dumping.swift.o Sources/Testing/CMakeFiles/Testing.dir/Running/Runner.RuntimeState.swift.o Sources/Testing/CMakeFiles/Testing.dir/Running/Runner.swift.o Sources/Testing/CMakeFiles/Testing.dir/Running/SkipInfo.swift.o Sources/Testing/CMakeFiles/Testing.dir/SourceAttribution/Backtrace.swift.o Sources/Testing/CMakeFiles/Testing.dir/SourceAttribution/CustomTestStringConvertible.swift.o Sources/Testing/CMakeFiles/Testing.dir/SourceAttribution/Expression.swift.o Sources/Testing/CMakeFiles/Testing.dir/SourceAttribution/Expression+Macro.swift.o Sources/Testing/CMakeFiles/Testing.dir/SourceAttribution/SourceContext.swift.o Sources/Testing/CMakeFiles/Testing.dir/SourceAttribution/SourceLocation.swift.o Sources/Testing/CMakeFiles/Testing.dir/SourceAttribution/SourceLocation+Macro.swift.o Sources/Testing/CMakeFiles/Testing.dir/Support/Additions/ArrayAdditions.swift.o Sources/Testing/CMakeFiles/Testing.dir/Support/Additions/CollectionDifferenceAdditions.swift.o Sources/Testing/CMakeFiles/Testing.dir/Support/Additions/CommandLineAdditions.swift.o Sources/Testing/CMakeFiles/Testing.dir/Support/Additions/NumericAdditions.swift.o Sources/Testing/CMakeFiles/Testing.dir/Support/Additions/ResultAdditions.swift.o Sources/Testing/CMakeFiles/Testing.dir/Support/CartesianProduct.swift.o Sources/Testing/CMakeFiles/Testing.dir/Support/CError.swift.o Sources/Testing/CMakeFiles/Testing.dir/Support/Environment.swift.o Sources/Testing/CMakeFiles/Testing.dir/Support/FileHandle.swift.o Sources/Testing/CMakeFiles/Testing.dir/Support/GetSymbol.swift.o Sources/Testing/CMakeFiles/Testing.dir/Support/Graph.swift.o Sources/Testing/CMakeFiles/Testing.dir/Support/JSON.swift.o Sources/Testing/CMakeFiles/Testing.dir/Support/Locked.swift.o Sources/Testing/CMakeFiles/Testing.dir/Support/SystemError.swift.o Sources/Testing/CMakeFiles/Testing.dir/Support/Versions.swift.o Sources/Testing/CMakeFiles/Testing.dir/Test.ID.Selection.swift.o Sources/Testing/CMakeFiles/Testing.dir/Test.ID.swift.o Sources/Testing/CMakeFiles/Testing.dir/Test.swift.o Sources/Testing/CMakeFiles/Testing.dir/Test+Discovery.swift.o Sources/Testing/CMakeFiles/Testing.dir/Test+Macro.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/Bug.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/Comment.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/Comment+Macro.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/ConditionTrait.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/ConditionTrait+Macro.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/HiddenTrait.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/ParallelizationTrait.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/SPIAwareTrait.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/Tags/Tag.Color.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/Tags/Tag.Color+Loading.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/Tags/Tag.List.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/Tags/Tag.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/Tags/Tag+Macro.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/Tags/Tag+Predefined.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/TimeLimitTrait.swift.o Sources/Testing/CMakeFiles/Testing.dir/Traits/Trait.swift.o -L /home/swm/workspace/debian/build/swiftlang/swiftlang-6.0.3/build/buildbot_linux/swifttesting-linux-x86_64/lib   -L /usr/lib/gcc/x86_64-linux-gnu/14 -Xlinker -rpath -Xlinker :::::::  lib/lib_TestingInternals.a  -ldispatch  -lFoundation  -lstdc++  -lm  -lgcc_s  -lgcc  -lc  -lgcc_s  -lgcc && :
error: unknown argument: '-Wl,-z,relro'
ninja: build stopped: subcommand failed.

finagolfin · 2025-03-19T09:18:16Z

Same CMake issue as with Foundation, same fix.

melizasw · 2025-03-19T14:40:37Z

Yep, thanks again. It was late at night and I had to give up even though I knew it wouldn't be too hard to find. Kicked off a new build, but I have to wait till after work tonight to see if it finishes or finds something new to error out on.

melizasw · 2025-03-20T14:42:06Z

That was indeed the last build error and I now have complete builds on x86_64 and aarch64. There are some packaging issues to work through and some additional testing to do, but that should all be fairly straight forward. Thank you all for the help.

melizasw · 2025-04-20T05:51:41Z

I'm now working on building Swift 6.1 using 6.0.3 and everything has been pretty smooth except for WASM. As far as I can tell WASM was not built as part of 6.0.3 even though it was present in the source code package.

The error is that when building wasmstdlib it errors out when trying to compile swift/lib/Demangling/Errors.cpp

error: option 'cf-protection=return' cannot be specified on this target
error: option 'cf-protection=branch' cannot be specified on this target

This is because -fcf-protection is being passed to clang++ (the one provided by Swift, not my system clang++). I cannot figure out where this flag is getting passed in from. The CMakeCache.txt file reports

CMAKE_CXX_FLAGS:STRING=-g -O2 -ffile-prefix-map=/home/swm/workspace/debian/build/swiftlang/swiftlang-6.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection

I also tried to find where -Wformat -Werror=format-security was coming from to see if that would help find the source. Best guess is that it might be coming from llvm-project/compiler-rt/cmake/Modules/CompilerRTUtils.cmake, but it doesn't have -fcf-protection in it. Grepping for -fcf-protection didn't turn up anything that looked like the culprit either.

Something else of note, when building 6.0.3 the test COMPILER_RT_HAS_FCF_PROTECTION_FLAG is ran once on the system clang and once on the Swift provided clang and both report Success. When building 6.1 these first two checks are the same, but then there are two more times this check is ran on the Swift provided clang 17 and they and all the other tests that get ran at that time report Failed. The first appears to be when building wasmllvmruntimelibs and the second when building wasmthreadsllvmruntimelibs. The subsequent build for wasmstdlib doesn't check for COMPILER_RT_HAS_FCF_PROTECTION_FLAG so I don't know if that is a factor or not.

Any ideas at what is going on with wasm?

Also, for 6.0.3 I was able to use the Debian provided wasi-libc, but with 6.1 it complains if I don't provide it the source code to compile and I don't see an easy way to turn it off in swift/utils/build-presets.ini like I've done in the past with other libraries. Is this possible?

melizasw · 2025-04-21T01:15:54Z

I disabled build-wasm-stdlib in swift/utils/build-presets.ini and was able to finish building 6.1 which confirms this is the only remaining build error on x86_64. I guess I could always initially ship 6.1 without wasmstdlib and add it later, so I'm going to probably file a bug report on that and turn my attention to wasi-libc.

melizasw · 2025-04-21T14:52:57Z

I've figured out to disable the wasi-libc compile I need to comment out builder.add_product(products.WASILibc, is_enabled=self.args.build_wasmstdlib) in swift/utils/swift_build_support/swift_build_support/build_script_invocation.py. This also helps me understand why I've not seen an issue with wasi-libc before. It is only used if wasmstdlib is being built and it was not being built for Linux in 6.0.3.

At any rate, I've gotten the wasi-libc build disabled and now just need to figure out the correct place to add the paths to the system libs(/usr/lib/wasm32-wasi/) and includes (/usr/include/wasm32-wasi/).

swiftlang-6.1/build/buildbot_linux/wasmllvmruntimelibs-linux-x86_64/include/c++/v1/stdlib.h:143:30: error: unknown type name 'ldiv_t'
  143 | inline _LIBCPP_HIDE_FROM_ABI ldiv_t div(long __x, long __y) _NOEXCEPT { return ::ldiv(__x, __y); }

Does anyone know where that happens?

This and the -fcf-protection error are hopefully the only issues I need to resolve to have wasm support.

melizasw · 2025-04-24T04:39:04Z

It turns out that Debian dpkg is who is adding the troublesome -fcf-Protection flags and I was able to turn them off by adding the following to debian/rules:

export CFLAGS += -fcf-protection=none
export CXXFLAGS += -fcf-protection=none

I've now completed a build of 6.1 with the exception of wasi-libc being that which Swift expects to be bundled with it instead of the system library. I'm still open to suggestions on that if anyone has any ideas.

melizasw added the new feature label Aug 22, 2022

finagolfin added the Linux Platform: Linux label Mar 17, 2025

Debian packaging support #60690

Debian packaging support #60690

Comments

melizasw commented Aug 22, 2022 • edited Loading

finagolfin commented Aug 22, 2022

melizasw commented Aug 22, 2022 • edited Loading

melizasw commented Aug 23, 2022 • edited Loading

finagolfin commented Aug 23, 2022 • edited Loading

melizasw commented Aug 23, 2022

melizasw commented Aug 27, 2022 • edited Loading

finagolfin commented Aug 29, 2022

melizasw commented Aug 30, 2022

melizasw commented Aug 31, 2022

finagolfin commented Aug 31, 2022 • edited Loading

melizasw commented Aug 31, 2022

tachoknight commented Aug 31, 2022

melizasw commented Aug 31, 2022

tachoknight commented Aug 31, 2022

melizasw commented Aug 31, 2022 • edited Loading

tachoknight commented Aug 31, 2022

finagolfin commented Aug 31, 2022

melizasw commented Aug 31, 2022

melizasw commented Aug 31, 2022

finagolfin commented Sep 1, 2022

melizasw commented Sep 1, 2022 • edited Loading

tachoknight commented Sep 1, 2022

melizasw commented Sep 1, 2022

finagolfin commented Sep 1, 2022

finagolfin commented Sep 1, 2022

tachoknight commented Sep 1, 2022

melizasw commented Sep 1, 2022

tachoknight commented Sep 1, 2022

melizasw commented Sep 1, 2022

yuzibo commented Nov 4, 2024

yuzibo commented Nov 4, 2024

melizasw commented Nov 4, 2024

tachoknight commented Nov 5, 2024 • edited Loading

tachoknight commented Nov 16, 2024

melizasw commented Nov 17, 2024 • edited Loading

melizasw commented Nov 17, 2024

melizasw commented Nov 18, 2024 • edited Loading

melizasw commented Nov 24, 2024 • edited Loading

melizasw commented Nov 26, 2024

melizasw commented Dec 21, 2024

melizasw commented Jan 7, 2025

etcwilde commented Jan 7, 2025

finagolfin commented Jan 27, 2025

melizasw commented Mar 17, 2025

finagolfin commented Mar 17, 2025

melizasw commented Mar 17, 2025

finagolfin commented Mar 17, 2025

melizasw commented Mar 18, 2025

finagolfin commented Mar 18, 2025

melizasw commented Mar 19, 2025 • edited Loading

melizasw commented Mar 19, 2025

finagolfin commented Mar 19, 2025

melizasw commented Mar 19, 2025

melizasw commented Mar 20, 2025

melizasw commented Apr 20, 2025

melizasw commented Apr 21, 2025

melizasw commented Apr 21, 2025

melizasw commented Apr 24, 2025

melizasw commented Aug 22, 2022 •

edited

Loading

melizasw commented Aug 22, 2022 •

edited

Loading

melizasw commented Aug 23, 2022 •

edited

Loading

finagolfin commented Aug 23, 2022 •

edited

Loading

melizasw commented Aug 27, 2022 •

edited

Loading

finagolfin commented Aug 31, 2022 •

edited

Loading

melizasw commented Aug 31, 2022 •

edited

Loading

melizasw commented Sep 1, 2022 •

edited

Loading

tachoknight commented Nov 5, 2024 •

edited

Loading

melizasw commented Nov 17, 2024 •

edited

Loading

melizasw commented Nov 18, 2024 •

edited

Loading

melizasw commented Nov 24, 2024 •

edited

Loading

melizasw commented Mar 19, 2025 •

edited

Loading