Thanks so much for the ebuild! I've wanted Swift on my Gentoo machines for a long time now but I found Swift's build process too intimidating to try to write an ebuild for it.
The 5.10.1-r1 ebuild works great and I'm compiling a copy of 6.0.1 now.
1 Like
Oh, that's great to hear! Happy you found this useful. Hope 6.0.1 works just as well, but if you run into any trouble, please don't hesitate to let me know! (Swift 6.0.1 for Gentoo on GURU)
here is my output of ulimit -a
-t: cpu time (seconds) unlimited
-f: file size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) 8192
-c: core file size (blocks) 0
-m: resident set size (kbytes) unlimited
-u: processes 255183
-n: file descriptors 1024
-l: locked-in-memory size (kbytes) 4194304
-v: address space (kbytes) unlimited
-x: file locks unlimited
-i: pending signals 255183
-q: bytes in POSIX msg queues 819200
-e: max nice 39
-r: max rt priority 95
-N 15: rt cpu time (microseconds) unlimited
and I can successful compile at step 2.
after compile, I still can't use swift
➜ bin ./swift
<unknown>:0: error: fatal error encountered during compilation; please submit a bug report (https://swift.org/contributing/#reporting-bugs)
<unknown>:0: note: Compiler-internal integrated REPL has been removed; use the LLDB-enhanced REPL instead.
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace.
Stack dump:
0. Program arguments: /tmp/a/swift-5.10.1/work/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift-frontend -frontend -repl -disable-objc-interop -color-diagnostics -plugin-path /tmp/a/swift-5.10.1/work/build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/host/plugins -plugin-path /tmp/a/swift-5.10.1/work/build/Ninja-ReleaseAssert/swift-linux-x86_64/local/lib/swift/host/plugins -module-name REPL
1. Swift version 5.10.1 (swift-5.10.1-RELEASE)
2. Compiling with the current language version
#0 0x000055f012e77008 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/tmp/a/swift-5.10.1/work/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift-frontend+0x8ee1008)
#1 0x000055f012e74ec2 llvm::sys::RunSignalHandlers() (/tmp/a/swift-5.10.1/work/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift-frontend+0x8edeec2)
#2 0x000055f012e77368 SignalHandler(int) Signals.cpp:0:0
#3 0x00007f8f8e4b3ad0 (/usr/lib64/libc.so.6+0x3bad0)
#4 0x00007f8f8e503f6c (/usr/lib64/libc.so.6+0x8bf6c)
#5 0x00007f8f8e4b3a26 raise (/usr/lib64/libc.so.6+0x3ba26)
#6 0x00007f8f8e49c4f5 abort (/usr/lib64/libc.so.6+0x244f5)
#7 0x000055f00d34f707 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*)::$_1::__invoke(void*, char const*, bool) FrontendTool.cpp:0:0
#8 0x000055f012d96716 llvm::report_fatal_error(llvm::Twine const&, bool) (/tmp/a/swift-5.10.1/work/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift-frontend+0x8e00716)
#9 0x000055f012d965fa (/tmp/a/swift-5.10.1/work/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift-frontend+0x8e005fa)
#10 0x000055f00d349218 performCompile(swift::CompilerInstance&, int&, swift::FrontendObserver*) FrontendTool.cpp:0:0
#11 0x000055f00d346cf4 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) (/tmp/a/swift-5.10.1/work/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift-frontend+0x33b0cf4)
#12 0x000055f00d2e1104 swift::mainEntry(int, char const**) (/tmp/a/swift-5.10.1/work/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift-frontend+0x334b104)
#13 0x00007f8f8e49df6e (/usr/lib64/libc.so.6+0x25f6e)
#14 0x00007f8f8e49e029 __libc_start_main (/usr/lib64/libc.so.6+0x26029)
#15 0x000055f00d2e03a5 _start (/tmp/a/swift-5.10.1/work/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift-frontend+0x334a3a5)
[1] 28259 IOT instruction (core dumped) ./swift
here is step 4 log
http://185.186.146.228:8000/emerge-swift_x.log
5.10.1-r1 build log
http://185.186.146.228:8000/emerge-swift-5.10.1-r1.log
Thanks for these logs! I'm really sorry for having wasted your time — the issue was probably staring right at me in the original logs, but I only found it after taking another read through here:
[3303/4412][ 74%][662.605s] cd /var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/tools/clang/runtime/compiler-rt-bins && /usr/bin/cmake -DCMAKE_C_COMPILER=/var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/./bin/clang -DCMAKE_CXX_COMPILER=/var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/./bin/clang++ -DCMAKE_ASM_COMPILER=/var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/./bin/clang -DCMAKE_BUILD_TYPE=Release -DCMAKE_MAKE_PROGRAM=/usr/bin/ninja -DCMAKE_C_COMPILER_LAUNCHER= -DCMAKE_CXX_COMPILER_LAUNCHER= -DLLVM_CONFIG_PATH=/var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/./bin/llvm-config "-DLLVM_LIT_ARGS=-sv -j 32" -DCOMPILER_RT_OUTPUT_DIR=/var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/./lib/clang/15.0.0 -DCOMPILER_RT_EXEC_OUTPUT_DIR=/var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/./bin -DCOMPILER_RT_INSTALL_PATH:PATH=lib/clang/15.0.0 -DCOMPILER_RT_INCLUDE_TESTS=ON -DCMAKE_INSTALL_PREFIX=/usr -DLLVM_LIBDIR_SUFFIX= -DLLVM_RUNTIME_OUTPUT_INTDIR=/var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/./bin -DCMAKE_OSX_DEPLOYMENT_TARGET= -DCMAKE_OSX_SYSROOT:PATH= -DCOMPILER_RT_BUILD_ORC=NO -DCOMPILER_RT_INTERCEPT_LIBDISPATCH=ON -DCOMPILER_RT_PREFIX=/var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/projects/compiler-rt -DCOMPILER_RT_SRC_ROOT=/var/tmp/portage/dev-lang/swift-5.10.1-r1/work/llvm-project/llvm/../compiler-rt -GNinja -S /var/tmp/portage/dev-lang/swift-5.10.1-r1/work/llvm-project/llvm/../compiler-rt -B /var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/tools/clang/runtime/compiler-rt-bins && /usr/bin/cmake -E touch /var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/tools/clang/runtime/compiler-rt-stamps/compiler-rt-configure
-- The C compiler identification is Clang 15.0.0
-- The CXX compiler identification is Clang 15.0.0
-- The ASM compiler identification is Clang with GNU-like command-line
-- Found assembler: /var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/bin/clang
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/bin/clang
-- Check for working C compiler: /var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/bin/clang - broken
e[31mCMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:67 (message):
The C compiler
"/var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/bin/clang"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: '/var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/tools/clang/runtime/compiler-rt-bins/CMakeFiles/CMakeScratch/TryCompile-CRvXeV'
Run Build Command(s): /usr/bin/ninja -v cmTC_ac6c3
[1/2][ 50%][0.019s] /var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/bin/clang -march=raptorlake -O2 -pipe -MD -MT CMakeFiles/cmTC_ac6c3.dir/testCCompiler.c.o -MF CMakeFiles/cmTC_ac6c3.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_ac6c3.dir/testCCompiler.c.o -c /var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/tools/clang/runtime/compiler-rt-bins/CMakeFiles/CMakeScratch/TryCompile-CRvXeV/testCCompiler.c
FAILED: CMakeFiles/cmTC_ac6c3.dir/testCCompiler.c.o
/var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/bin/clang -march=raptorlake -O2 -pipe -MD -MT CMakeFiles/cmTC_ac6c3.dir/testCCompiler.c.o -MF CMakeFiles/cmTC_ac6c3.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_ac6c3.dir/testCCompiler.c.o -c /var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/tools/clang/runtime/compiler-rt-bins/CMakeFiles/CMakeScratch/TryCompile-CRvXeV/testCCompiler.c
error: unknown target CPU 'raptorlake'
note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont, goldmont-plus, tremont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, broadwell, skylake, skylake-avx512, skx, cascadelake, cooperlake, cannonlake, icelake-client, rocketlake, icelake-server, tigerlake, sapphirerapids, alderlake, knl, knm, k8, athlon64, athlon-fx, opteron, k8-sse3, athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, btver2, bdver1, bdver2, bdver3, bdver4, znver1, znver2, znver3, x86-64, x86-64-v2, x86-64-v3, x86-64-v4
ninja: build stopped: subcommand failed.
The failure was 100–200 lines up in the log; it's just that so much is compiling in parallel that we get a lot of successful log output after the fact. 
It looks like the clang built by LLVM here doesn't recognize your CPU architecture specifically:
/var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/bin/clang -march=raptorlake -O2 -pipe -MD -MT CMakeFiles/cmTC_ac6c3.dir/testCCompiler.c.o -MF CMakeFiles/cmTC_ac6c3.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_ac6c3.dir/testCCompiler.c.o -c /var/tmp/portage/dev-lang/swift-5.10.1-r1/work/build/Ninja-Release/llvm-linux-x86_64/tools/clang/runtime/compiler-rt-bins/CMakeFiles/CMakeScratch/TryCompile-CRvXeV/testCCompiler.c
error: unknown target CPU 'raptorlake'
note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont, goldmont-plus, tremont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, broadwell, skylake, skylake-avx512, skx, cascadelake, cooperlake, cannonlake, icelake-client, rocketlake, icelake-server, tigerlake, sapphirerapids, alderlake, knl, knm, k8, athlon64, athlon-fx, opteron, k8-sse3, athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, btver2, bdver1, bdver2, bdver3, bdver4, znver1, znver2, znver3, x86-64, x86-64-v2, x86-64-v3, x86-64-v4
The raptorlake arch is newer than clang 15, which is why it isn't recognized. I'm assuming your /etc/portage/make.conf has COMMON_FLAGS="-march=raptorlake -O2 -pipe", which is used to populate CFLAGS — and if so, I'm guessing you were able to compile outside of the sandbox is that you don't have CFLAGS="-march=raptorlake..." set in your environment (whereas it's explicitly set by emerge in the sandbox).
The default COMMON_FLAGS specify -march=native -O2 -pipe, which clang would recognize (and should get you near-identical behavior), but I'm guessing you have a good reason to specify your exact architecture in general.
If this is the case and I'm on the right track, you might be able to install by overriding the flags by:
- Creating
/etc/portage/env/swift-cflagswith the contentsCFLAGS="${CFLAGS} -march=native" CXXFLAGS="${CXXFLAGS} -march=native" - Adding
dev-lang/swift swift-cflagsto/etc/portage/package.env
and reinstalling swift-5.10.1-r1. (You could also change /etc/portage/make.conf, but that's a much larger change that would likely prompt recompilation of a lot of software.)
This specifically is an expected failure — the stage0 compiler is very limited in scope, and things like the repl and libraries are unavailable. The ebuild then uses the stage0 compiler to build a stage1 compiler with some libs, then that to compile a stage2 compiler, which is the final product which gets installed.
Nice, I can success to compile it. Thanks for your help.
1 Like
BTW, I set export SWIFT_BACKTRACE=enable=yes env, and when I run swift , it throws
swift runtime: unable to locate swift-backtrace; disabling backtracing.
but under GitHub - swift-server/swift-backtrace: 💥 Backtraces for Swift on Linux and Windows
Note: You do not need this library on Linux as of Swift 5.9, which has built-in backtracing support.
gentoo builds swift don't support backtrace?
when program trigger a assert failed, I can't get symbolized stack
xxx.swift:1830: Assertion failed
Current stack trace:
0 libswiftCore.so 0x00007f68b8ff5a60 _swift_stdlib_reportFatalErrorInFile + 109
1 libswiftCore.so 0x00007f68b8c90c78 <unavailable> + 2690168
2 libswiftCore.so 0x00007f68b8c90a97 <unavailable> + 2689687
3 libswiftCore.so 0x00007f68b8c8fa90 _assertionFailure(_:_:file:line:flags:) + 490
4 xx 0x00005630e6ba38c2 <unavailable> + 14919874
5 xx 0x00005630e6ba2c14 <unavailable> + 14916628
6 xx 0x00005630e6bbb297 <unavailable> + 15016599
7 xx 0x00005630e6bb7fb8 <unavailable> + 15003576
8 xx 0x00005630e6bb7aa6 <unavailable> + 15002278
but using offical swift binary, I can get symbolized stack trace.
Fantastic! Glad you were able to get things up and running.
Good question — at the moment, no, but this is something I'm actively working on fixing. On Linux, Swift uses an out-of-process backtracer, which is an exectuable that must be found on disk somewhere; by default, this is in /usr/libexec/swift/linux, a directory that Gentoo forbids packages from installing files to. To get an initial package built, I disabled building the libexec binaries, and I just haven't had the time to properly investigate turning things back on.
It might be possible to just have the backtracer installed in the toolchain itself (so, /usr/lib64/swift-x.y.z/usr/libexec/linux/...) — if the runtime can find it there by default, then this is a trivial fix; if not and the runtime needs to be configured with an explicit path for where the backtracer will be installed, then it might be slightly more work to set up.
Hope to have progress on this soon!
Get it, thanks for your reply.
1 Like
I can confirm, by the way, that the runtime can find the backtracer if it's installed directly into the toolchain, so restoring backtracing is as trivial as removing build-swift-libexec=0 from the compilation flags. 
I'd like to collect a few more bug fixes before putting together swift-5.10.1-r2 and swift-6.0.1-r1 with this, given the onerous compile times.
2 Likes