Hi,
can anyone help to bring back Swift to FreeBSD? FreshPorts -- lang/swift: Swift programing language I think this would be very welcome. I would love to run my swift server side projects on FreeBSD.
Thank you!
Hi,
I am giving it a shot atm but would love some help if at all possible :-)
In particular (and sorry if this is the wrong place to ask for help on this) I am having some trouble building Swift.swiftmodule:
cd /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/stdlib/public/core && /usr/local/bin/cmake -E remove -f /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./lib/swift/freebsd/x86_64/Swift.swiftmodule /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./lib/swift/freebsd/x86_64/Swift.swiftdoc /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./lib/swift/freebsd/x86_64/Swift.swiftinterface && /usr/local/bin/cmake -E make_directory /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./lib/swift/freebsd/x86_64 && /usr/home/fpierfed/dev/venvs/swift-source/bin/python /usr/home/fpierfed/swift-source/swift/utils/line-directive @/usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/stdlib/public/core/FnaL8.txt -- /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./bin/swiftc -emit-module -o /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./lib/swift/freebsd/x86_64/Swift.swiftmodule -sdk / -target x86_64-unknown-freebsd12.0-RELEASE -resource-dir /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./lib/swift -O -g -D INTERNAL_CHECKS_ENABLED -D SWIFT_ENABLE_RUNTIME_FUNCTION_COUNTERS -I /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./lib/swift/freebsd/x86_64 -module-cache-path /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./module-cache -no-link-objc-runtime -enable-library-evolution -Xfrontend -verify-sil-ownership -Xfrontend -enable-mandatory-semantic-arc-opts -Xfrontend -enforce-exclusivity=unchecked -nostdimport -parse-stdlib -module-name Swift -Xfrontend -group-info-path -Xfrontend /usr/home/fpierfed/swift-source/swift/stdlib/public/core/GroupInfo.json -swift-version 5 -warn-swift3-objc-inference-complete -Xfrontend -verify-syntax-tree -Xllvm -sil-inline-generics -Xllvm -sil-partial-specialization -Xcc -DswiftCore_EXPORTS -warn-implicit-overrides -module-link-name swiftCore -force-single-frontend-invocation -parse-as-library -emit-parseable-module-interface-path /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./lib/swift/freebsd/x86_64/Swift.swiftinterface @/usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/stdlib/public/core/FnaL8.txt
/usr/home/fpierfed/swift-source/swift/stdlib/public/core/FloatingPointTypes.swift.gyb:1109:12: error: use of unresolved identifier '_stdlib_remainderl'
self = _stdlib_remainderl(self, other)
^~~~~~~~~~~~~~~~~~
SwiftShims._stdlib_remainder:1:13: note: did you mean '_stdlib_remainder'?
public func _stdlib_remainder(_ _self: Double, _ _other: Double) -> Double
^
SwiftShims._stdlib_remainderf:1:13: note: did you mean '_stdlib_remainderf'?
public func _stdlib_remainderf(_ _self: Float, _ _other: Float) -> Float
^
/usr/home/fpierfed/swift-source/swift/stdlib/public/core/FloatingPointTypes.swift.gyb:1151:12: error: use of unresolved identifier '_stdlib_squareRootl'
self = _stdlib_squareRootl(self)
^~~~~~~~~~~~~~~~~~~
SwiftShims._stdlib_squareRoot:1:13: note: did you mean '_stdlib_squareRoot'?
public func _stdlib_squareRoot(_ _self: Double) -> Double
^
SwiftShims._stdlib_squareRootf:1:13: note: did you mean '_stdlib_squareRootf'?
public func _stdlib_squareRootf(_ _self: Float) -> Float
^
ninja: build stopped: subcommand failed.
./utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting
Does this ring a bell? Needless to say,
swift/stdlib/public/SwiftShims/LibcShims.h
Includes definitions for these function...
Thank you!
Francesco
1 Like
__i386__ or __x86_64__ is not defined in your environment which is why these functions are not exposed to the standard library.
#if !defined _WIN32 && (defined __i386__ || defined __x86_64__)
static inline SWIFT_ALWAYS_INLINE
long double _stdlib_remainderl(long double _self, long double _other) {
return __builtin_remainderl(_self, _other);
}
static inline SWIFT_ALWAYS_INLINE
long double _stdlib_squareRootl(long double _self) {
return __builtin_sqrtl(_self);
}
#endif
You can just change second condition to (defined __i386__ || defined __x86_64__ || defined __FreeBSD__) although I'm not sure this is a very clean solution. The compiler understands you're on x86_64 because the #if arch(x86_64) succeeds and implements Float80. cc: @scanon
Yeah, this is not the solution you want--we want to figure out why __x86_64__ is not defined in the Clang that is being used by Swift to import these C decls, because that will probably cause other issues as well.
You will probably need to explicitly link the math library as well at some point (it's implicitly linked on Darwin, but not Linux or FreeBSD)--you should be able to copy whatever happens for Linux.
IIRC the FreeBSD math library doesn't (or didn't at one point) contain some of the long double functions, so you may end up needing to if them out in tgmath.swift.gyb, but you haven't made it that far yet, so don't worry about it until you do.
Is it better for them to just skip Float80 until we figure out the header issue?
Depends on how much of a rush they're in. And whether or not they want to use Float80 =)
There are a bunch of things which rely on correctly identifying the target. You will end up with more issues until you fix this. Furthermore, seems like something is fundamentally broken:
$ clang -target x86_64-unknown-freebsd -x c -E /dev/null -dM -o - | grep __x86_64__
#define __x86_64__ 1
2 Likes
That's.. interesting.
Yup: that's correct:
# git diff stdlib/public/SwiftShims/LibcShims.h
diff --git a/stdlib/public/SwiftShims/LibcShims.h b/stdlib/public/SwiftShims/LibcShims.h
index fd0aef2783..f0323a3300 100644
--- a/stdlib/public/SwiftShims/LibcShims.h
+++ b/stdlib/public/SwiftShims/LibcShims.h
@@ -148,7 +148,6 @@ double _stdlib_squareRoot(double _self) {
return __builtin_sqrt(_self);
}
-#if !defined _WIN32 && (defined __i386__ || defined __x86_64__)
static inline SWIFT_ALWAYS_INLINE
long double _stdlib_remainderl(long double _self, long double _other) {
return __builtin_remainderl(_self, _other);
@@ -158,7 +157,6 @@ static inline SWIFT_ALWAYS_INLINE
long double _stdlib_squareRootl(long double _self) {
return __builtin_sqrtl(_self);
}
-#endif
// Apple's math.h does not declare lgamma_r() etc by default, but they're
// unconditionally exported by libsystem_m.dylib in all OS versions that
and the error persists:
error: use of unresolved identifier '_stdlib_remainderl'
self = _stdlib_remainderl(self, other)
^~~~~~~~~~~~~~~~~~
SwiftShims._stdlib_remainder:1:13: note: did you mean '_stdlib_remainder'?
etc.
So it looks like somehow Float80 support might not be there for FreeBSD????
On a related note, if I remove support for Float80, compilation proceeds but linking libswiftCore.so fails with
/usr/bin/ld.lld: error: undefined symbol: __atomic_load
>>> referenced by atomic:926 (/usr/include/c++/v1/atomic:926)
>>> stdlib/public/runtime/CMakeFiles/swiftRuntime-freebsd-x86_64.dir/HeapObject.cpp.o:(swift_verifyEndOfLifetime)
etc.
Look into the build system, you need to link against libatomic. There was existing support for that, but might've missed the FreeBSD case.
Unfortunately libatomic exists only as part of GCC, not standalone (in FreeBSD at least). Libatomic_ops is deprecated and does not export these symbols.
Linking against the GCC libatomic gives some other missing symbols, btw
Is it trying to build against libstdc++ instead of libc++? The latter may work better if you're trying to avoid gcc dependencies. If the existing freebsd support is c&p-ed from Linux it may be explicitly asking for libstdc++ for no good reason.
Some more info on the __atomic_* undefined references on FreeBSD here: 230888 – Missing 64 bit atomic functions for i386 (libatomic)
@Joe_Groff - even libc++ used libatomic to provide the atomics. However, there was a recent change to libc++ to provide a freestanding atomic implementation without the library. @fpierfed, you should try building with the top of tree libc++ and see if that helps.
1 Like
I might have been able to sidestep the __atomic_* issue but now I am getting another error (both using clang7 from FreeBSD 12 and the newly built one as part of the Swift build process):
(swift-source) swift # ./utils/build-script --release-debuginfo --host-cc=~/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-freebsd-x86_64/bin/clang --host-cxx=~/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-freebsd-x86_64/bin/clang++ -j 1
./utils/build-script: note: Using toolchain default
+ mkdir -p /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert
Building the standard library for: swift-test-stdlib-freebsd-x86_64
+ /usr/local/bin/cmake --build /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/cmark-freebsd-x86_64 -- -j1 all
ninja: no work to do.
symlinking the system headers (/usr/include/c++) into the local clang build directory (/usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-freebsd-x86_64/include).
+ ln -s -f /usr/include/c++ /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-freebsd-x86_64/include
+ /usr/local/bin/cmake --build /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-freebsd-x86_64 -- -j1 all
ninja: no work to do.
+ /usr/local/bin/cmake --build /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64 -- -j1 all swift-test-stdlib-freebsd-x86_64
[1/33][ 3%][2.250s] Compiling /usr/home/fpierfed/...6_64/stdlib/public/Platform/FREEBSD/x86_64/Glibc.o
FAILED: stdlib/public/Platform/FREEBSD/x86_64/Glibc.o
cd /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/stdlib/public/Platform && /usr/home/fpierfed/dev/venvs/swift-source/bin/python /usr/home/fpierfed/swift-source/swift/utils/line-directive @/usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/stdlib/public/Platform/nRKDM.txt -- /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./bin/swiftc -c -sdk / -target x86_64-unknown-freebsd12.0-RELEASE -resource-dir /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./lib/swift -O -g -D INTERNAL_CHECKS_ENABLED -D SWIFT_ENABLE_RUNTIME_FUNCTION_COUNTERS -I /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./lib/swift/freebsd/x86_64 -module-cache-path /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./module-cache -no-link-objc-runtime -enable-library-evolution -Xfrontend -verify-sil-ownership -Xfrontend -enable-mandatory-semantic-arc-opts -Xfrontend -enforce-exclusivity=unchecked -module-name Glibc -swift-version 5 -swift-version 4 -autolink-force-load -warn-swift3-objc-inference-complete -Xfrontend -verify-syntax-tree -warn-implicit-overrides -module-link-name swiftGlibc -force-single-frontend-invocation -parse-as-library -o /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/stdlib/public/Platform/FREEBSD/x86_64/Glibc.o @/usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/stdlib/public/Platform/nRKDM.txt
Assertion failed: (VD->isFileVarDecl() && "Cannot emit local var decl as global."), function EmitGlobal, file /usr/home/fpierfed/swift-source/llvm/tools/clang/lib/CodeGen/CodeGenModule.cpp, line 2200.
Stack dump:
0. Program arguments: /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/bin/swift -frontend -c /usr/home/fpierfed/swift-source/swift/stdlib/public/Platform/Platform.swift /usr/home/fpierfed/swift-source/swift/stdlib/public/Platform/TiocConstants.swift /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/stdlib/public/Platform/8/tgmath.swift /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/stdlib/public/Platform/8/Glibc.swift -target x86_64-unknown-freebsd12.0-RELEASE -disable-objc-interop -sdk / -I /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./lib/swift/freebsd/x86_64 -autolink-force-load -warn-swift3-objc-inference-complete -warn-implicit-overrides -enable-library-evolution -g -module-cache-path /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./module-cache -module-link-name swiftGlibc -resource-dir /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/./lib/swift -swift-version 4 -O -D INTERNAL_CHECKS_ENABLED -D SWIFT_ENABLE_RUNTIME_FUNCTION_COUNTERS -verify-sil-ownership -enable-mandatory-semantic-arc-opts -enforce-exclusivity=unchecked -verify-syntax-tree -enable-anonymous-context-mangled-names -parse-as-library -module-name Glibc -o /usr/home/fpierfed/swift-source/build/Ninja-RelWithDebInfoAssert/swift-freebsd-x86_64/stdlib/public/Platform/FREEBSD/x86_64/Glibc.o
1. While emitting IR SIL function "@$s5Glibc7environSpySpys4Int8VGSgGvg".
for getter for environ (at /usr/home/fpierfed/swift-source/swift/stdlib/public/Platform/Platform.swift:408:12)
#0 0x0000000005215188 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /usr/home/fpierfed/swift-source/llvm/lib/Support/Unix/Signals.inc:495:13
#1 0x00000000052134a5 llvm::sys::RunSignalHandlers() /usr/home/fpierfed/swift-source/llvm/lib/Support/Signals.cpp:70:18
#2 0x0000000005215a08 SignalHandler(int) /usr/home/fpierfed/swift-source/llvm/lib/Support/Unix/Signals.inc:358:1
#3 0x00000008054014b6 (/lib/libthr.so.3+0x134b6)
ninja: build stopped: subcommand failed.
./utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting
(swift-source) swift #
Hmm, my guess is that environ is not a normal symbol in the FreeBSD libc (IIRC, it was obscured through a macro). I would say take a look at the Glibc SDK overlay and adjust the computed environ property.
Anything new here? 
2 Likes
Any new progress?
1 Like
Ping 
would love to run my new app backend on FreeBSD. Please, help and support FreeBSD
1 Like