FreeBSD compatibility patch #4804
Conversation
…usr/local/include for now
add /usr/local/include to include path in stdlib/public/stubs use FreeBSD procfs path to cmdline when building for FreeBSD
Things like: PthreadBarriers.swift:114:50: error: cannot convert value of type 'UnsafeMutablePointer<pthread_mutex_t>' (aka 'UnsafeMutablePointer<OpaquePointer>') to expected argument type 'UnsafeMutablePointer<pthread_mutex_t?>' (aka 'UnsafeMutablePointer<Optional<OpaquePointer>>') on barrier.pointee.mutex . I need to do more research to understand this
|
@swift-ci Please smoke test |
Note that these wrappers are necessary to build and run the testsuite, which is essential in declaring Swift actually working on the platform. Please add FIXMEs to these |
Why isn't |
| "fatal error: Unable to open interface to '/proc/self/cmdline'.\n"); | ||
| "fatal error: Unable to open interface to '" | ||
| PROCFS_CMDLINE_PATH | ||
| "'.\n"); |
There was a problem hiding this comment.
Changes to this file LGTM, feel free to submit as a separate PR if you would like them to be merged immediately.
| @@ -14,6 +14,10 @@ | |||
| // | |||
| //===----------------------------------------------------------------------===// | |||
|
|
|||
| #if defined(__FreeBSD__) | |||
| #define _WITH_GETLINE | |||
| #endif | |||
There was a problem hiding this comment.
Changes to this file LGTM, feel free to submit as a separate PR if you would like them to be merged immediately.
| @@ -35,6 +37,7 @@ module SwiftGlibc [system] { | |||
| header "${GLIBC_INCLUDE_PATH}/complex.h" | |||
| export * | |||
| } | |||
| % if CMAKE_SDK != "FREEBSD": | |||
There was a problem hiding this comment.
I don't see a matching %end being added, is this intentional?
There was a problem hiding this comment.
Not intentional, fixed in a subsequent commit, thanks!
|
@gribozavr : thanks for your feedback, I'll take your suggestions into account in the coming days! |
|
great work! Freebsd RC3 just release yesterday. Does your patch work on it too? |
|
Indeed, the patch appears to work on RC3 as well; same provisions apply though: the bare swift(c) compiles and runs. |
…D"]' (assuming some time more kqueue-supported platforms will want to support Swift)
|
@swift-ci Please test |
| @@ -58,6 +58,11 @@ extern "C" char ** _swift_stdlib_getUnsafeArgvArgc(int *outArgLen) { | |||
| return *_NSGetArgv(); | |||
| } | |||
| #elif defined(__linux__) || defined(__CYGWIN__) || defined(__FreeBSD__) | |||
| #if defined(__FreeBSD__) | |||
There was a problem hiding this comment.
Since /proc is optional and not mounted by default, I'd recommend using sysctl(3) here. The MIB you want is { CTL_KERN, KERN_PROC, KERN_PROC_ARGS, getpid() }
There was a problem hiding this comment.
Great pointer, thanks! I was never quite happy with requiring /proc to be mounted.. Hope commit ede70f2 is a better FreeBSD fit.
|
I'm happy to take FreeBSD 12 patches later, just to get this in. We normally prefer small positive changes over big merges anyway. (40 commits is already much bigger than we'd like, even if most of them are edits and merges.) |
@myfreeweb, I would not expect the linker to ever implicitly add anything. Linkers can follow library dependencies of static archives in some (but not all) situations. I would however expect the clang driver to add libc to most linker invocations. Is your build invoking the linker directly or via clang? |
|
@llvm-beanz I just built it using the build script |
|
@myfreeweb I think it is probable that the issue you're seeing with libc missing in the linker options is either a bug in swift's driver or a bug in clang's. It would be great if you could capture the command in the swift build that is generating the error, so that we can attempt to reproduce. |
|
I just finished a build successfully using the build script on FreeBSD 11.0-RELEASE. However I had to use swift/utils/update-checkout --tag swift-DEVELOPMENT-SNAPSHOT-2016-11-15-a and then merge this pull request to get a working result. I'm using this build-script command:
My previous builds (using the same build-script invocation) with the current master and this pull request merged finished without any build errors, too – but then I could neither run the Swift REPL nor build any working executables using swiftc. I got these errors: Did I miss something? I feel like I actually did right, because the build-script invocation produced a working result in the same environment using that development snapshot. Any ideas? EDIT: I have also attached a system call trace from |
|
@jrose-apple Do you think it would be better to squash the commits? |
|
@swift-ci Please smoke test and merge |
|
For the record: I do like tidy histories and meaningful commits even on merge branches, but I do see that they're an extra hoop for contributors to jump through, so I mostly haven't been pushing it on PR reviews. If we were using rebase-and-merge it would be a different story. |
|
Thanks for the merge!! |
|
I'm sorry your first pull request took months to settle and merge! You're doing good work; glad to have you contributing. |
|
@kstaring congrats! Is there any documentation for build instruction on Freebsd and maybe a package(there is swift 2 on freshport already) |
|
build fail on my freebsd 11 uname -r |
|
@mko-io do you have gold installed? It's in the |
|
I just finished another build with the current master branch and got the same issues when executing: As I mentioned before the tag This produced an output which reveals differences. As you can see in the diff +libswiftCore.a
+libswiftCore.so
+Reflection.mm.o
+sil-func-extractor
+sil-passpipeline-dumper
+sil-nm
-sil-extractI understand that the symbol refers to an exception handling personality function. But I can't figure out, what is wrong with my environment in FreeBSD 11.0-RELEASE – why the symbol cannot be resolved – despite the whole build process being successful. Any ideas @kstaring @myfreeweb ? EDIT: I finally managed to produce a working Swift standard library now. Therefore I had to link the core standard library with gnustep's libobjc2, which I installed with |
|
@myfreeweb Thank you. I'll try it again |
|
The required packages are cmake ninja icu libxml2 sqlite3 swig python27 pkgconf py27-sphinx e2fsprogs-libuuid I'll install a clean jail tomorrow and will see if I get a port ready to submit. I'm bound to run into the trouble nether-cat encountered that way, I suppose. Any packages I forgot to mention will become clear that way as well. |
|
@kstaring awesome!! |
|
From a clean FreeBSD 11.0-RELEASE build, the following packages are required to build and run swiftc, as well as executables compiled with said swiftc. Git, python, cmake, ninja, pkgconf and bash are obviously only necessary to build swift itself. I can confirm that a fresh build of swiftc produces binaries with the undefined symbol __gnustep_objcxx_personality_v0 . It can be solved with a little workaround, and that's why libobjc2 is included in the list of packages to install: add " The cause lies with llvm's CGException.cpp. I didn't expect a regression this quickly ;-) I'll try to make a port out of this and include a fix, to be included in a new PR as well. Will keep you posted! I didn't encounter other reported problems yet. To be thorough; it sometimes helps to completely remove the build directory before building once more. At times some bizarre problems surface which can be solved by simply starting over.. |
|
Oof. We really shouldn't be linking libobjc on FreeBSD. The exception personality function comes from a C++ stdlib, not an ObjC one. |
|
I have submitted an issue here: https://bugs.swift.org/browse/SR-3635 – I will also keep trying to find the reason for __gnustep_objcxx_personality_v0 being used on FreeBSD. 👀 |
|
Friendly check any update on this? I'm trying to follow the issue submitted by @nether-cat https://bugs.swift.org/browse/SR-3635, the status is unsolved, does it mean it's been working on or unsolvable? |
[pull] swiftwasm-release/5.7 from release/5.7
This patch lets the current Swift 3 codebase compile on FreeBSD. The specific version tested with is FreeBSD 11-RELEASE.
The swift binary runs and perhaps more importantly, swiftc is able to at least compile simple programs-- more complicated code simply haven't been tested yet so more claims cannot be made.
This patch incoorporates some of @tinysun212 PR https://github.com/apple/swift/pull/3886/files#diff-99fd89ad44c4466de8ad6b8aab9c207d