Debian packaging support #60690
Comments
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
Surely Debian allows exceptions for developer tools like this that need those symbols to work? |
That was a great idea. The llvm-toolchain-14 package has 840 lint errors including this one: 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'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. |
|
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. 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. These don't need to be executable do they? I'm not even sure just how they are getting +x. 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? 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. If anyone can help make sense of any of these lintian issues that would be most helpful. |
|
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.
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.
For now I'm going to let the Debian build scripts copy over the file and see if that resolves things.
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.
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.
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! |
|
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? |
No, I doubt there's even that much doc on it. |
|
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. |
|
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. |
Are you sure the compiler build even uses |
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): I'm not likely to be doing any debug or pull requests on this any time soon as I'm focused on packaging. |
|
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 |
|
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. |
|
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. |
|
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. 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. |
|
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. |
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. |
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? |
Ah, you're right, found it. The current build checks for both |
|
@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. |
|
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 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 |
|
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. |
|
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. |
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. |
|
Ah, that's right, I was remembering it incorrectly. |
|
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:
|
|
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. |
|
Swift 5.6.3 list the following valid hosts for Linux: This would seem to mean that i686, armv6, and armv7 are valid 32-bit hosts. However, the only hosts from this list that Debian supports are x86_64, i686, aarch64, powerpc64, and s390x (powerpc and riscv64 as well). So I think I can just restrict my package to building on these 5 architectures. x86_64 builds I'm working to fix these, but any help would be appreciated. Also, I'm curious how to add support for powerpc and riscv64 since they were added in 5.7.x or newer and thus there is no swift compiler on those platforms to use to compile. |
IIRC 32-bit host support was dropped long before (or hadn’t ever existed). Latest PRs that add new architectures show they’re adding support for targets that are meant to be cross-compiled against. 32-bit ARMv8 host triples should be handled similarly, while 64-bit ones can be mapped into
Maybe the port is not maintained any more and should be removed?
|
@melizasw In fact, you can tweak the process to first build a toolchain without Swift in Swift support, and then build another one with it. This still works as for Swift 5.9, but will be removed at some time. |
|
Ok, I think the problem is that I was approaching the Swift build process with the notion that it supported a wider range of architectures than it does. I see now that tachoknight's packaged for Fedora only supports x86_64 and aarch64. For an optional development tool it seems reasonable to have a smaller set of supported architectures to start with. Debian does indeed support the addition of new architectures and I was able to find some documentation on bootstrapping and cross-building which may be needed for riscv64 support. But for now I think I'm going to just focus on x86_64 and aarch64 and maybe s390x (Debian's LLVM toolchain builds for s390x). Thanks for the help. |
Fedora supports multiple architectures as well and for a very brief time I had everything working on the x390 platform, but then a newer version of clang would crash with a stacktrace when building Swift. I filed a bug with the LLVM team that has gotten no traction at all, so I abandoned it. FYI I would like to know your experience building 5.9 on Debian/aarch64 because currently Fedora doesn't build successfully on that platform (builds and works fine on x86_64). |
Yep, I ran into the same problem and added to your bug report from 3+ years ago. There was some activity on the bug 2 months ago, but no fix yet. I guess no s390x for now.
It'll take a while before I get there, but I will let you know.
That beats the 2.5 days it took to build through QEMU! I ordered an RPI 5 that will be here in a few days to help out with that problem. I've also got a LicheePi 4A arriving later today to help me with building for riscv64 which I have been making some progress on by porting patches from @futurejones to 5.6.3. |
|
Great news - Swift is now on Debian unstable (sid) and in a few days should go out to testing (trixie) on amd64 and arm64. Unfortunately when Ubuntu pulled it in and attempted to build on Noble it failed. The issue appears to me to be related to the gold linker The same build on Debian produces the following build log: I'm not sure why Debian is skipping the check but Ubuntu is not and then failing it. My Debian build doesn't have LLVMgold.so so no surprise that Ubuntu doesn't have it either. I'm going to try the following to see if they help:
Any help or advice would be appreciated as at the moment I am not set up to run test builds on Ubuntu and cannot directly test these without first releasing them to Debian then waiting for Ubuntu to pull it in and build. |
|
More good news. Swift has now migrated to Debian testing and the two fixes mentioned above did indeed get the Ubuntu Noble build past that hang-up. I drug an old system out of retirement and installed Ubuntu on it so that I could work through the build errors on Noble. Unfortunately now I'm getting another error, something about trying to link a shared library and needed to compile with -fPIC. That doesn't seem too hard, I just need to find the right place to do so when I get more time. |
|
@melizasw I have installed and tried to test your debian packages but they don't work. The test environment is a Debian Trixie docker container. docker run --cap-add=SYS_PTRACE --security-opt seccomp=unconfined -it debian:trixie /bin/bashapt updateapt install swiftlangmkdir hello && cd hello && swift package init --type executable && swift runroot@d5e164273bb5:/# mkdir hello && cd hello && swift package init --type executable && swift run
Creating executable package: hello
Creating Package.swift
Creating README.md
Creating .gitignore
Creating Sources/
Creating Sources/hello/main.swift
Creating Tests/
Creating Tests/helloTests/
Creating Tests/helloTests/helloTests.swift
'hello': error: invalidManifestFormat("<module-includes>:1:10: note: in file included from <module-includes>:1:\n#include \"CoreFoundation.h\"\n
^\n/usr/libexec/swift/lib/swift/CoreFoundation/CoreFoundation.h:25:10: error: \'sys/types.h\' file not found\n#include <sys/types.h>\n
^\n/usr/libexec/swift/lib/swift/CoreFoundation/CFStream.h:20:10: note: while building module \'CDispatch\' imported from /usr/libexec/swift/lib/swift/CoreFoundation/CFStream.h:20:\n#include <dispatch/dispatch.h>\n
^\n<module-includes>:1:10: note: in file included from <module-includes>:1:\n#include \"dispatch.h\"\n ^\n/usr/libexec/swift/lib/swift/dispatch/dispatch.h:32:10: note: in file included from
/usr/libexec/swift/lib/swift/dispatch/dispatch.h:32:\n#include <os/generic_unix_base.h>\n
^\n/usr/libexec/swift/lib/swift/os/generic_unix_base.h:24:10:
error: \'sys/param.h\' file not found\n#include <sys/param.h>\n
^\n<unknown>:0: error: could not build C module \'CoreFoundation\'", diagnosticFile: nil)
root@d5e164273bb5:/hello# This error also occurs when using Debian Unstable. When trying to build using root@d5e164273bb5:/hello# swiftc Sources/hello/main.swift
error: link command failed with exit code 1 (use -v to see invocation)
clang-13: error: invalid linker name in argument '-fuse-ld=gold'This indicates that root@d5e164273bb5:/hello# swiftc Sources/hello/main.swift
error: link command failed with exit code 1 (use -v to see invocation)
/usr/bin/ld.gold: error: cannot open Scrt1.o: No such file or directory
/usr/bin/ld.gold: error: cannot open crti.o: No such file or directory
/usr/bin/ld.gold: error: cannot open crtbeginS.o: No such file or directory
/usr/bin/ld.gold: error: cannot open crtendS.o: No such file or directory
/usr/bin/ld.gold: error: cannot open crtn.o: No such file or directory
/usr/bin/ld.gold: error: cannot find -lgcc
/usr/bin/ld.gold: error: cannot find -lgcc_s
/usr/bin/ld.gold: error: cannot find -lc
/usr/bin/ld.gold: error: cannot find -lgcc
/usr/bin/ld.gold: error: cannot find -lgcc_s
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)I have filed a bug with Debian to track the issue. |
|
@futurejones this is due to missing dependencies on binutils and gcc. If you install these two packages it will get you up and running for the next few days until I can get a new release out. |
|
@melizasw there appears to be a problem with the relationship between the different The The The |
|
@futurejones I can certainly do that. Can you help me understand though what use swiftlang is without swiftlang-dev? I was under the impression that swiftlang wasn't of much use without both libswiflang and swiftland-dev. |
|
So first, I'm really happy to see this work making progress. I think this will really help with the Swift-on-Linux story. For some ideas on the separation of the libraries and tools, it might be worth looking at the Windows installer. I don't remember the exact split but it does a good job of separating concerns for developers, CI, and end-consumers of Swift programs. You shouldn't need to download the compiler if you just want to run a pre-compiled program that happens to be written in Swift, and you shouldn't need to download the headers for CoreFoundation if you just want to build a hello-world, for instance. It looks like that separation is mostly covered with the separation of I may have missed a few runtime libraries in the listing here, so worth double-checking, but I think it's reasonable breakdown: Runtimes:
* The challenge with libdispatch is that concurrency depends on it. The C bits of corelibs-libdispatch actually get built twice in the toolchain build, so I wonder if it would make sense to configure the build to emit a static archive so that we don't expose that. Then We should keep the runtime libraries together installed as one. I don't have a strong opinion on the corelibs libraries being together or apart, though mildly in favor of keeping them together as a Looking at Build Tools: (what I assume is the umbrella
The swift-clang will be an interesting tricky bit. We'll want to provide the special swift-clang that has support for swift and swift-async calling conventions so that folks can use the C and C++ interop features. That of course conflicts with the existing clang package. I think the My concern with naming clang
Dev Tools:
Same sort of situation with the swift-lldb as with clang. The lldb from apple/llvm-project has extra bits to make debugging Swift work, but that will conflict with the existing Anyway, my initial thoughts. Thank you for working on this. |
|
Despite what was said above about building Swift 5.7.3 using Swift 5.6.3, I tried without Swift and was able to build 5.7.3 just fine and am in the process of getting that pushed out into Debian. In the mean time I decided to build Swift 5.8.1 without using Swift 5.7.3, which I think should be possible as @tachoknight did so for Fedora. However, I got this bootstrapping error quite similar to what @stevapple got nearly 2 years ago in Windows - #61410 Here is my version of the error, or at least the start of about 5,000 lines of them.
I can't figure out what is causing this error. Is there a way around it or do I need to give up and build 5.8.1 with 5.7.3? |
|
I've not been able to make any progress on the above error when trying to build Swift 5.8.1 without a Swift compiler installed. I tried turning off bootstrapping, but that gave me errors that were equally as confusing. I am mostly trying to build without a Swift compiler as I still have hope that I can get a riscv build going and support for it looks to be better in 5.8.1 than in 5.7.3 and I still don't have it working yet. Another reason that I was not building with a swift compiler installed is that that flow was broken too so I figured I may as well try one way then the other. Building with a swift compiler was broken because on an x86_64 Debian system clang will identify as pc-linux-gnu so I had to build swift 5.7.3 for pc-linux-gnu and swift/utils/swift_build_support/swift_build_support/products/product.py is hard coded to use unknown-linux. This was causing the build scripts to not detected a working swift compiler on x86_64. Arm64 and RiscV Debian systems identify as unknown-linux-gnu and thus are not affected. It's not a Swift bug per se as I had to edit swift/cmake/modules/SwiftConfigureSDK.cmake to build as pc-linux-gnu. Now that I'm trying to build Swift 5.8.1 using an installed swift 5.7.3, do I need to set bootstrapping to hosttools? |
|
Problem resolved, though I certainly took the scenic route to get there. The issue is covered in good detail in #65028 so no need to repeat it. Swift 5.8.x apparently introduced some cmake file changes that are not compatible with cmake 3.25 and newer. Once I uninstalled Debian's cmake the build reverted to the specified version of cmake (3.19.6) and this build error went away. Looks like the patch will be in 5.9.x. |
|
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? |
|
@melizasw Many thanks for your work on Debian packaging. Now the issue is below: although the log is suggestive enough, but I am not convinced a little. Could you have an idea about this? Certainly, I will continue to try it on my side. TIA. |
|
@yuzibo Yes, I got 5.8.1 into Debian by using the clang-18 package as my workaround for now. However, the arm64 build passes with Clang 16 and fails with Clang 18 so I have my work cut out for me there. Yes, I am familiar with the ld cannot find Scrt1.o error on RISCV. I've been slowly chipping away at it, but the patches in Debian are close, but not complete yet. My build is still running so I don't know yet if these are enough, but try adding them to your patches: If these work then I'll need to figure out a clean way to only enable them for RISCV and not the other architectures. I've gathered my RISCV patches from various sources, but these two changes are thanks to @futurejones and his patches for 5.8 - https://github.com/swift-riscv/swift-riscv64/tree/bcb3fad816f5dd89fcc38804a5d5a1b0a58a1bc3/patches/release-5.8-branch I've not incorporated all of his patches as I try to only enable them as needed to fix a specific error so that I can understand the need for each one and make sure I don't grab any that are not needed for Debian. I've already got 5.9.2 building on x86_64 with a build depends on 5.8.1 so RISCV really needs to get onboard at 5.8.1 or it will get left behind and require some cross building or bootstrapping later on. |
|
@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. |
|
@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. |
|
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. |
I added this to my build script and it works now: |
|
@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: 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 |
|
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
|
|
I have 5.9.2 building fine on x86_64, but on aarch64:
Sigh ETA: Self-induced with a patch that hard coded that path. |
|
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: aarch64: Swiftc 5.8.1 on aarch64 does not print this message. Does anyone have an idea on this one? |
|
5.9.2 is now building on Arm after modifying swift/include/swift/Runtime/Config.h to match Debian's page sizes. |
|
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. |
@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
debuildtool 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.cppuses a non-free license and is located in three places: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: