ld, mold work. lld, gold don't

[mcarans]

I have tested various linkers. The Flatpak runtime default linker is gold - it doesn't link with the Oolite deployment build.

lld 20 and 21 both cause a segmentation fault when the game starts. I have created an issue with the LLVM Project and with libobjc2 in case the problem somehow is there which seems unlikely.

ld (bfd) the standard linker works in all cases including flatpak. I also tested mold and it works on Ubuntu and flatpak.

[mcarans]

I learnt something new. You can make a reproducible tar to recreate problems with linkers.

To do this in GNUmakefile set:

Code: Select all

    ADDITIONAL_LDFLAGS           = -fuse-ld=lld  
    ADDITIONAL_LDFLAGS           += -Wl,--reproduce=/tmp/rep.tar

Comment these link time optimisation lines in that file:

Code: Select all

    ifeq ($(lto),yes)
        ADDITIONAL_CFLAGS        += -flto
        ADDITIONAL_OBJCFLAGS     += -flto
        ADDITIONAL_CCFLAGS       += -flto
        ADDITIONAL_LDFLAGS       += -flto
    endif

Run make -f Makefile release-deployment then unpack the /tmp/rep.tar file produced.

Copy the Resources folder from an existing oolite.app to the unpacked rep.tar folder.

Then you can do ld.lld @response.txt to produce the oolite executable.

You can test different linkers eg. mold @response.txt or ld.bfd @response.txt for the gcc linker.

I've created a reproduce tar for the issue I raised with LLVM project: https://github.com/llvm/llvm-project/is ... 3695092366

[Lone_Wolf]

Perhaps the most significant change is the absence of the "gold" linker, which is deprecated and about to disappear entirely. Gold appeared in 2008 with some fanfare as a faster linker, but it has suffered from a lack of maintenance in recent years.

see https://lwn.net/Articles/1007541/

Don't bother with gold linker.

[mcarans]

Perhaps the most significant change is the absence of the "gold" linker, which is deprecated and about to disappear entirely. Gold appeared in 2008 with some fanfare as a faster linker, but it has suffered from a lack of maintenance in recent years.

see https://lwn.net/Articles/1007541/

Don't bother with gold linker.

I wouldn't have bothered with gold, but surprisingly, it is still the standard linker in the flatpak runtime which prompted this investigation.

[mcarans]

I found that rebuilding libjs_static.a rather than using the one in the repo which is really old fixes it for the lld linker. As with oolite_splash, I will need to use zig to target older glibc or build on older ubuntu rather than using the .a I built locally with gcc.

[mcarans]

I have made a repo for building spidermonkey from source on Linux: https://github.com/mcarans/spidermonkey-linux

I've used it to build on Ubuntu 22.04 a libjs_static.a file to update the one we currently use: https://github.com/OoliteProject/oolite ... ies/pull/4

[mcarans]

With AI assistance, I was able to debug the lld linking problem with old SpiderMonkey and provide a summary to the LLVM devs - basically that lld seems to omit relative relocations:

https://github.com/llvm/llvm-project/is ... 4131570768

Turns out this was an intentional change in lld in 2021: https://maskray.me/blog/2021-11-07-init ... transition

The main thing is it's not a bug and that the solution is simple and already checked in: rebuild libjs_static.a with gcc on Ubuntu 22.