Strange error when compiling Swift on GNU/Linux


(Saleem Abdulrasool) #21

They haven't been removed, you are considering the architecture not the full target. Look at the android build.

(Eben Up) #22

The problem is that the build system is very elaborate and complex and you're asking me to modify something I don't understand. I could take a few days I suppose to analyze the system and map out how it works on a whiteboard, but that seems like a misallocation of labor i.e. I'm not sure I'm the one who should be doing that in the first place, it's the responsibility of whoever created it. I just want swiftc on GNU/Linux, built safely from sources.

As GCC doesn't provide atomics, the build system should have been modified by whoever wrote it, who knows it well enough to not break it, to take into account that libatomic has to be linked in.

(Saleem Abdulrasool) #23 clearly indicates that it is already linking against libatomic ;-). How is it that your build is not honouring that? Are you perhaps using a different distribution? A different CMake version? Some other local alterations?

(Eben Up) #24

I see that line in my AddSwift.cmake file too. My /usr/bin/cmake is version 3.13.4.
I did a new git pull a day ago and found there were changes, but I just did another one now and there are quite a few more changes.
I'll try compiling to determine if these help.

(Saleem Abdulrasool) #25

Hmm, what linker are you using? ld.bfd is known to not work, and IIRC, gold's semantics vary just enough to make alterations in the ordering work.

(Eben Up) #26

OK indeed /usr/bin/ld symlinks to ld.bfd.
I also have installed so I symlinked to that instead.
The new build attempt however broke in the same way.

I decided to redo the build, however my assumption that the build system was using GCC seems to have been wrong, as ps shows it is using clang 7.

(Eben Up) #27

I switched distros and I am now seeing an odd Python error.
What could this mean?

(Saleem Abdulrasool) #28

Make sure that you are using python 2.7

(Eben Up) #29

Yes I realized it was defaulting to python 3.6.5.
Changing the first line of the update-checkout script to say python2.7 rather than just python fixed it.

Unfortunately I am still getting an error at the end, after doing a fresh git clone and update-checkout --clone.

/home/user/swift-source/swift failed (ret=1): ['git', 'rebase', 'FETCH_HEAD']
Cannot rebase: You have unstaged changes.
Please commit or stash them.
update-checkout failed, fix errors and try again.

Of course, the rebase fails because I had to modify one file, the update-checkout script, because it was written assuming only 1 version of python is installed, when in fact my GNU/Linux has two.

(Eben Up) #30

And now some new errors. Compiling on Debian this time, the build script can't find

(Saleem Abdulrasool) #31

Those are dependencies that you are expected to provide. You should be able to install them using your distro's package manager.

(Eben Up) #32

Yes but what I said was that I did already install them.
apt install udid
apt install libxml2
And yet... they were not found.

(John McCall) #33

Did you install them after getting that error? You might need to delete your CMakeCache.txt.

(Saleem Abdulrasool) #34

That installs the user side of it, not the developer side of it. IIRC, Ubuntu calls them libxml2-devel and possibly uuid-devel.

(Ben Langmuir) #35

Close! It's -dev rather than -devel. The list of dependencies for Ubuntu is at

(Eben Up) #36

The latest error occurs when a GR option is being checked for. However it is written as /GR so the compiler thinks it refers to a directory. So it looks like something from Windows.
I'm starting to wonder if I will ever get this compiler compiled. Everything looks too unstable. As far as I can tell, I'm still just compiling clang.