Trying to build on FreeBSD

Because, why not, right? However, I'm... not even sure what is necessary for it. Well, that's not entirely true -- I did read the file, and I got various packages for FreeBSD installed (including cmake and ninja). I ported libdispatch-913.60.2, and that's one of the current, ahem, sources of trouble -- the include files and libraries are in /usr/local, and I don't know how to tell the build system that it should check there. I assume I'm missing something very obvious, which, sadly happens with me.

I am building with:
% ./utils/build-script --skip-build-benchmarks --skip-build-cmark --skip-build-llvm --skip-build-foundation --skip-ios --skip-watchos --skip-tvos --swift-darwin-supported-archs uname -m --release-debuginfo --swift-disable-dead-stripping --test

Merci beaucoup!

1 Like

Heh, where did you get that build-script command? It makes no sense.

I assume you're building on a FreeBSD host, in which case all the Apple flags aren't needed. Unfortunately, the docs only show examples for macOS and not linux, but there is an OpenBSD page, which you should look at.

I'd try a basic ./swift/utils/build-script --release-debuginfo --test to begin with, which should just build the Swift compiler and stdlib and test them. It probably won't work because of some missing FreeBSD support, so you should try searching for linux and OpenBSD in the codebase and add FreeBSD checks where needed.

Take a look at this person's work adding OpenBSD support (though you should start with the compiler, not Foundation): you will need to modify most of the same places, though there is some FreeBSD support already.

Swift uses a forked LLVM, so you will have to wait awhile for that to build first. If you hit anything you can't figure out, let us know here.

1 Like

I wasn't aware of the OpenBSD one, that'll help, thanks.

The nutso build command was figured out by the existing documentation, looking at the source, and figuring out what wouldn't work.

Hi @sef, you aren't the first one trying to build Swift on FreeBSD. There was some sort of effort before, search the archives. Also, it seems FreeBSD decided to fork Swift instead of bringing their changes back to upstream yet. There is for instance GitHub - landonf/swift-freebsd: The Swift Programming Language by Landon Fuller ( https://landonf.org ) , one of the FreeBSD devs which wasn't updated since December 2015 … maybe you try to reach out to him.

Good luck!

Lars

1 Like

Yeah, something that's over 5 years out of date isn't too helpful ;). I looked at the freebsd port that was removed last year, it was for swift 3 -- and I decided to just try from the current version, since it already had Windows and Linux support, so I figured that'd be a bit friendlier.

I get:

-- Looking for include file xpc/xpc.h
-- Looking for include file xpc/xpc.h - not found
-- Skipping creating early SwiftDriver symlinks - no early SwiftDriver build found.
-- Configuring incomplete, errors occurred!
See also "/usr/home/sef/src/build/Ninja-DebugAssert/swift-freebsd-x86_64/CMakeFiles/CMakeOutput.log".
See also "/usr/home/sef/src/build/Ninja-DebugAssert/swift-freebsd-x86_64/CMakeFiles/CMakeError.log".
ERROR: command terminated with a non-zero exit status 1, aborting

and I'm not sure what is failing. Oh! Perhaps it is:

/usr/bin/clang -DC_SUPPORTS_INDEX_STORE -Wno-unknown-warning-option -Werror=unguarded-availability-new -fPIC -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wdelete-non-virtual-dtor -Wstring-conversion -Wmisleading-indentation -Werror -index-store-path "/usr/home/sef/src/build/Ninja-DebugAssert/swift-freebsd-x86_64/CMakeFiles/CMakeTmp/IndexStore" -MD -MT CMakeFiles/cmTC_faaa5.dir/src.c.o -MF CMakeFiles/cmTC_faaa5.dir/src.c.o.d -o CMakeFiles/cmTC_faaa5.dir/src.c.o -c src.c
clang: error: unknown argument: '-index-store-path'
clang: error: no such file or directory: '/usr/home/sef/src/build/Ninja-DebugAssert/swift-freebsd-x86_64/CMakeFiles/CMakeTmp/IndexStore'
ninja: build stopped: subcommand failed.

which would be an issue with my version of clang?

No, I don't think that's it, as only the Apple clang has that flag anyway and it builds fine on linux without it.

An annoying thing about CMake is that it will spit out the error and keep going, so run the command again and scroll up in the final log output to find the error: it won't be at the end.

Just for completeness, CMark and LLVM built fine? Those are dependencies of building the Swift compiler, and cannot be skipped as you were originally trying. And what system CMake and clang versions are you using?

I was not building cmark, because I have a version of it already installed. Looks like LLVM built fine. clang is 11.0.1, cmake is 3.20.1, and cmark is 0.29.0

I am using the OpenBSD instructions (with a couple of changes, so far, for FreeBSD), and am getting a C++ error:

In file included from ~/src/Swift/swift/lib/Basic/BasicSourceInfo.cpp:13:
In file included from ~/src/Swift/swift/include/swift/AST/ASTContext.h:27:
In file included from ~/src/Swift/swift/include/swift/AST/Types.h:21:
~/src/Swift/swift/include/swift/AST/AutoDiff.h:430:49: error: call to implicitly-deleted copy constructor of 'union Value'
: functionType(functionType), kind(kind), value(Value()) {
^ ~~~~~~~
~/src/Swift/swift/include/swift/AST/AutoDiff.h:423:18: note: copy constructor of 'Value' is implicitly deleted because variant field 'typeAndIndex' has a non-trivial copy constructor
TypeAndIndex typeAndIndex;
^
1 error generated.

C++ is really not my language, so I'm not sure what the error means, nor why it's happening.

Help?

Changing the unions to structs fixes those problems, but now I've got:

~/src/Swift/swift/tools/swift-dependency-tool/swift-dependency-tool.cpp:34:1: error: redefinition of 'ScalarTraits<unsigned long, void>'
LLVM_YAML_DECLARE_SCALAR_TRAITS(size_t, QuotingType::None)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~/src/Swift/llvm-project/llvm/include/llvm/Support/YAMLTraits.h:2030:22: note: expanded from macro 'LLVM_YAML_DECLARE_SCALAR_TRAITS'
template <> struct ScalarTraits {
^~~~~~~~~~~~~~~~~~
~/src/Swift/llvm-project/llvm/include/llvm/Support/YAMLTraits.h:1186:8: note: previous definition is here
struct ScalarTraits<uint64_t> {
^
1 error generated.

Sean,

I'm afraid I cannot help with the C++ error, but I have a couple of
questions. First, are you building a release, or are you building the
latest on a development branch? Second, could your Swift compiler
sources be written for a different edition of C++ (e.g., C++11) than
your compiler options select (e.g., -std=c++17)? I ask these questions
because it seems strange that the Swift compiler should ordinarily be in
an un-buildable state.

I would really like to see you succeed and I will try to help where I
can. I hope the foundations set by the OpenBSD & FreeBSD ports will
help a port to NetBSD, because I would like to use Swift there.

Dave

First, are you building a release, or are you building the
latest on a development branch?

"main"

could your Swift compiler
sources be written for a different edition of C++ (e.g., C++11) than
your compiler options select (e.g., -std=c++17)

I honestly have no idea, nor how to tell. As I said, my C++ knowledge is fairly limited.

For what it's worth, the compiler by default is C++14, but can do C++17 and C++20.

I can't help you with the C++ issues either- I stay away from that abomination, which is why I'm using Swift- but as Dave says, you just checked out some random commit from trunk? I suggest you use a snapshot commit instead, which you can get with update-checkout or by manually checking a tag out with git.

The most recent snapshots are from May 18 and if you're still getting these strange C++ errors, you could try building the same snapshot on linux and compare the particular build command and preprocessed file to see if there are any significant differences.

Checking out swift-5.4-RELEASE does not result in any changes to the errors while building, or the patches I've needed to make. In particular, I still had to change the union to struct, and I still get the type redefinition error. :frowning:

ETA: Oh, I do get the new error

~/src/Swift/swift/include/swift/AST/FineGrainedDependencyFormat.h:16:10: fatal error: 'llvm/Bitcode/RecordLayout.h' file not found

#include "llvm/Bitcode/RecordLayout.h"

If you check out a particular tag of the compiler source, you have to do the same for LLVM. I suggest you check out the latest trunk snapshot tag of cmark, LLVM, and Swift, then try to build that.

With everything checked out to swift-5.4-RELEASE, I still get this error:

~/src/Swift/swift/tools/swift-dependency-tool/swift-dependency-tool.cpp:34:1: error: redefinition of 'ScalarTraits<unsigned long, void>'
LLVM_YAML_DECLARE_SCALAR_TRAITS(size_t, QuotingType::None)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~/src/Swift/llvm-project/llvm/include/llvm/Support/YAMLTraits.h:1999:22: note: expanded from macro 'LLVM_YAML_DECLARE_SCALAR_TRAITS'
template <> struct ScalarTraits {
^~~~~~~~~~~~~~~~~~
~/src/Swift/llvm-project/llvm/include/llvm/Support/YAMLTraits.h:1200:8: note: previous definition is here
struct ScalarTraits<uint64_t> {
^
1 error generated.
[962/1062][ 90%][4448.238s] Building CXX object tools/swift-ide-test/CMakeFiles/swift-ide-test.dir/swift-ide-test.cpp.o

That line is preprocessed out on linux and Win64, maybe you need to do the same on BSD.

Ok, yay! That got me past all of that! But now:

self = _stdlib_remainderl(self, other)
       ^~~~~~~~~~~~~~~~~~

~/Swift/swift/stdlib/public/core/FloatingPointTypes.swift.gyb:766:12: error: cannot find '_stdlib_squareRootl' in scope
self = _stdlib_squareRootl(self)
^~~~~~~~~~~~~~~~~~~
ninja: build stopped: subcommand failed.
ERROR: command terminated with a non-zero exit status 1, aborting

31919.100u 2383.304s 31:16.53 1827.9% 84577+849k 0+0io 769817pf+0w

It is easy to find where that should be defined:

> grep -r _stdlib_squareRootl .
./stdlib/public/SwiftShims/LibcShims.h:long double _stdlib_squareRootl(long double _self) {

I see this a couple lines above, does FreeBSD not define __x86_64__?