Switch clang build to LLVM's lld linker

[mcarans]

I recall that a long while ago I tested using lld with the Windows build and it was noticeably faster at linking producing a working executable. I didn't suggest switching at the time because when I tested on Linux, the Oolite binary segfaulted. Now that I've established that the Linux problem was down to the SpiderMonkey static library being compiled on very old gcc, I think it would be safe to switch for clang builds on both platforms. The Windows clang build always had a recently compiled SpiderMonkey and now the Linux build does too (built on Ubuntu 22 to retain compatibility for older systems).

It seems to make logical sense to use the LLVM linker with the LLVM compiler especially for Obj-C. lld is said to be between 2 and 10 times faster than bfd although it is less noticeable on my machine with Linux than with Windows from what I remember. lld is said to use less RAM. On Linux, the lld linked binary for deployment is slightly smaller than the bfd linked one. Not sure if that's also true for Windows. A big help is that lld's error messages are easier to understand than bfd's.

Setting the linker is done like this:

Code: Select all

ADDITIONAL_LDFLAGS       += -fuse-ld=lld

Replace lld with bfd for the default GNU linker.

[another_commander]

From C:\DevEnvUCRT\msys64\ucrt64\share\GNUstep\Makefiles\config.make, line 129:

Code: Select all

LDFLAGS = -fuse-ld=lld -lstdc++ -lgcc_s

Confirming by building Oolite with make debug=no messages=yes, link command output:

Code: Select all

/ucrt64/bin/clang++ -Wl,--enable-auto-import     -fuse-ld=lld -lstdc++ -lgcc_s  -fexceptions  -fobjc-runtime=gnustep-2.2 -fblocks  -o obj.win.spk/oolite.exe \
./obj.win.spk/oolite.obj/legacy_random.c.o [...]

We have been using lld from the first moment we switched to clang.

[mcarans]

From C:\DevEnvUCRT\msys64\ucrt64\share\GNUstep\Makefiles\config.make, line 129:

Code: Select all

LDFLAGS = -fuse-ld=lld -lstdc++ -lgcc_s

Confirming by building Oolite with make debug=no messages=yes, link command output:

Code: Select all

/ucrt64/bin/clang++ -Wl,--enable-auto-import     -fuse-ld=lld -lstdc++ -lgcc_s  -fexceptions  -fobjc-runtime=gnustep-2.2 -fblocks  -o obj.win.spk/oolite.exe \
./obj.win.spk/oolite.obj/legacy_random.c.o [...]

We have been using lld from the first moment we switched to clang.

Great! Thanks for checking. It's only Linux that needs to be switched over.

[Lone_Wolf]

keep in mind that there are now 2 things needed to switch from gcc to clang

- gnustep libobjc2, gnustep-make , gnustep-base build with clang
- libjs build with clang

This will lead to having to support 2 deviating sets of 4 libraries with oolite :
one build with clang and one build with gcc

Or is the intention of devs to switch to only support llvm/clang builds in the near future ?

[hiran]

Again something for the backlog.

viewtopic.php?t=22072

[mcarans]

keep in mind that there are now 2 things needed to switch from gcc to clang

- gnustep libobjc2, gnustep-make , gnustep-base build with clang
- libjs build with clang

This will lead to having to support 2 deviating sets of 4 libraries with oolite :
one build with clang and one build with gcc

Or is the intention of devs to switch to only support llvm/clang builds in the near future ?

The new Linux libjs is built with the gcc version that is in Ubuntu 22 not clang. This was necessary because old gcc does something that is deliberately not supported by new lld, details of which are here: viewtopic.php?p=304675#p304675. It's only the GNUstep libraries that must be built using clang to use Oolite with clang.

On Windows the MinGW64 environment is used for gcc while the UCRT64 environment is for clang. The only gcc build that could be considered for retirement at the moment is the very old legacy gcc Windows build since there is a modern gcc build. I would however like the clang build to be the main build on all platforms since the GNUstep devs seem to be mostly focused on clang builds of their packages.