missing support for -dT, SCRIPTFILE, --default-script=SCRIPTFILE

[kalebskeithley]

From the linux binutils ld.info file (note: for whatever reason this is not in the binutils ld(1) man page or ld --help: ... '-dT SCRIPTFILE' '--default-script=SCRIPTFILE' Use SCRIPTFILE as the default linker script. *Note Scripts::.

 This option is similar to the '--script' option except that
 processing of the script is delayed until after the rest of the
 command line has been processed.  This allows options placed after
 the '--default-script' option on the command line to affect the
 behaviour of the linker script, which can be important when the
 linker command line cannot be directly controlled by the user.  (eg
 because the command line is being constructed by another tool, such
 as 'gcc').

...

And in fact fedora koji autoconf builds do generate makefiles with -dT ..., which then fail to build because mold does not recognize the option, e.g.:https://kojipkgs.fedoraproject.org//work/tasks/1690/82181690/build.log

Or here's an except for when that build.log file disappears: ... make[3]: Entering directory '/builddir/build/BUILD/glusterfs-10.1/glusterfsd/src' /bin/sh ../../libtool --tag=CC --mode=link gcc -Wall -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -I/usr/include/uuid -I/usr/include/tirpc -Wformat -Werror=format-security -Werror=implicit-function-declaration -flto -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -ltcmalloc_minimal -rdynamic -fuse-ld=mold -ltirpc -flto -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/glusterfs-10.1/.package_note-glusterfs-10.1-3.fc36.x86_64.ld -o gf_attach gf_attach.o ../../libglusterfs/src/libglusterfs.la ../../api/src/libgfapi.la ../../rpc/rpc-lib/src/libgfrpc.la ../../rpc/xdr/src/libgfxdr.la -lrt -lpthread -lcrypto -ltcmalloc_minimal libtool: link: gcc -Wall -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -I/usr/include/uuid -I/usr/include/tirpc -Wformat -Werror=format-security -Werror=implicit-function-declaration -flto -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -rdynamic -fuse-ld=mold -flto -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT -Wl,/builddir/build/BUILD/glusterfs-10.1/.package_note-glusterfs-10.1-3.fc36.x86_64.ld -o .libs/gf_attach gf_attach.o ../../libglusterfs/src/.libs/libglusterfs.so ../../api/src/.libs/libgfapi.so -lacl /builddir/build/BUILD/glusterfs-10.1/rpc/rpc-lib/src/.libs/libgfrpc.so ../../rpc/rpc-lib/src/.libs/libgfrpc.so /builddir/build/BUILD/glusterfs-10.1/rpc/xdr/src/.libs/libgfxdr.so ../../rpc/xdr/src/.libs/libgfxdr.so /builddir/build/BUILD/glusterfs-10.1/libglusterfs/src/.libs/libglusterfs.so -ltirpc -lz -lm -luuid -ldl -lurcu-bp -lurcu-common -lurcu-cds -lrt -lpthread -lcrypto -ltcmalloc_minimal mold: unknown command line option: -dT collect2: error: ld returned 1 exit status ...

[rui314]

I don't think --default-scrip makes sense for mold. Here is why.

Linker script is very important to GNU ld. It's not just an embedded language for the linker, but in fact the default behavior of the linker is implemented using the "default linker script". In GNU ld, everything is configurable by a linker script, and the linker is implemented using the linker script itself.

There are pros and cons of that design. That gives you some flexibility but it made the linker more complicated, fragile and slow.

In contrast, in mold, we support only a very limited set of linker script features. Its default behavior is directly implemented in C++ rather than in linker script. Therefore, there's no notion of "default linker script" in mold.

The notion of the default linker script is very GNU-specific. Since our design is different, it cannot be supported.

[kalebskeithley]

I don't think --default-scrip makes sense for mold. Here is why.

Then can you make it silently ignore them?

[rui314]

If a program is using --default-script, there's a reason for them to use it, so I don't think we can't just ignore it. Do you know why your program specifies that flag?

[kalebskeithley]

It's added by the fedora koji build system and outside of my control.

There are hacks I can do to get around it when I do a build in koji; I can run a find+sed script that removes -dT... from all the generated makefiles, but it's pretty brittle. If Fedora adds more options then my find+sed script will break.

ISTR seeing that mold tries to be compatible with gnu/binutils ld, at least as far as using many of the same command line options. Is silently ignoring --default-script really so bad?

In the end you're going to do whatever you want, and I will have to hack around it if I want to use mold. Or just not use mold. :-}

[rui314]

I downloaded the source code of Fedora Koji by git clone https://pagure.io/koji.git, but I couldn't find any occurrence of -dT or --default-script in that repository. Are you sure that Fedora Koji added that flag to your build? It seems like it was added by someone else.

[kalebskeithley]

There's a lot more than just koji; there's also mock and *.rpm.macros and probably other things I don't know about.

The gluster build where I'm seeing the issue does not add -dT. I don't know where it comes from, but it's not from my package.

[rui314]

We can't ignore a given command line argument unless we know it's safe to ignore it. If -dT was added to your build system for a reason, we can't ignore it, and if not, it should have been just be removed from the build system. So we can't ignore -dT just to silence the error.