Support `libdep` plugin about mold

[rui314]

If no one uses it and bfd's implementation is broken, we don't want to support it. I wonder why it is supported via the plugin mechanism -- bfd could have supported as a native feature.

[rui314]

I think we should support that unless it is too difficult to do so. Let me take a look.

[haampie]

It looks like binutils supports basic quoting:

https://github.com/bminor/binutils-gdb/blob/master/ld/libdep_plugin.c#L136-L212

So -L "/hello 'world'" and -L '/hello "world"' are parsed as ["-L", "/hello 'world'"] and ["-L", "/hello \"world\""].

Escaping with \ looks broken to me 🤔 https://github.com/bminor/binutils-gdb/blob/6a4f078b5b8b442f474a8af804c316783d216a4e/ld/libdep_plugin.c#L165-L169, it doesn't escape anything, it just drops the character and continues parsing.

[haampie]

Ok, maybe nobody ever uses libdep cause I struggle to make the -L flag work.

Here's a simple example where libg.a cannot be located, even though libf.a specifies the correct -L flag:

LDFLAGS := -Wl,--plugin,/usr/lib/x86_64-linux-gnu/bfd-plugins/libdep.so

.PHONY: all clean

all: exe

f/f.o:
	mkdir -p f
	printf 'extern int g(); int f(){ return g(); }' | $(CC) -c -xc - -o $@

f/libf.a: f/f.o g/libg.a
	$(AR) crl '-L$(CURDIR)/g -lg' $@ $<

g/g.o:
	mkdir -p g
	printf 'int g(){ return 4; }' | $(CC) -c -xc - -o $@

g/libg.a: g/g.o
	$(AR) cr $@ $<

exe: f/libf.a
	printf 'extern int f(); int main() { return f(); }' | $(CC) $(LDFLAGS) -xc - -o $@ -Lf -lf

clean:
	rm -f exe f/f.o f/libf.a g/g.o g/libg.a

$ make
mkdir -p f
printf 'extern int g(); int f(){ return g(); }' | cc -c -xc - -o f/f.o
mkdir -p g
printf 'int g(){ return 4; }' | cc -c -xc - -o g/g.o
ar cr g/libg.a g/g.o
ar crl '-L/tmp/tmp.iR9g9xEukO/g -lg' f/libf.a f/f.o
printf 'extern int f(); int main() { return f(); }' | cc -Wl,--plugin,/usr/lib/x86_64-linux-gnu/bfd-plugins/libdep.so -xc - -o exe -Lf -lf
got deps for library f/libf.a: -L/tmp/tmp.iR9g9xEukO/g -lg
/usr/bin/ld: f/libf.a(f.o): in function `f':
<stdin>:(.text+0xe): undefined reference to `g'

If I set -Lg/ in the LDFLAGS it works... so, looks like the plugin fails to register the search path.

$ make LDFLAGS='-Wl,--plugin,/usr/lib/x86_64-linux-gnu/bfd-plugins/libdep.so -Lg'
printf 'extern int f(); int main() { return f(); }' | cc -Wl,--plugin,/usr/lib/x86_64-linux-gnu/bfd-plugins/libdep.so -Lg -xc - -o exe -Lf -lf
got deps for library f/libf.a: -L/tmp/tmp.iR9g9xEukO/g -lg
$ ./exe # works

If you don't see any obvious issues with the above I'll report the bugs upstream.

---

Edit: it works with -fuse-ld=gold, it doesn't work with -fuse-ld=bfd.

So, it's a very much broken feature, likely rarely used... but I do think that conceptually __.LIBDEP is better than pkg-config files etc.

---

Filed https://sourceware.org/bugzilla/show_bug.cgi?id=31904 and https://sourceware.org/bugzilla/show_bug.cgi?id=31906

[haampie]

I've submitted a fix for the parser here https://sourceware.org/pipermail/binutils/2024-June/134936.html. Never contributed to binutils before, do you know anyone who could review that?

Will look into the bfd issue later when I have time.

[haampie]

I'm closing this for now. In my opinion the libdep.so plugin is poorly designed and not worth implementing in mold until it has improved.

I still wish there was a way to make static linking resolve dependencies like in dynamic linking though. But the way binutils is doing it is far from optimal.

I suggested in their mailing list to:

1. Change the API of ar from ar --record-libdeps="-Lfoo -lbar" to ar --libdep-arg=-Lfoo --libdep-arg=lbar or similar, so that users don't have to worry about double quoting (once for the shell, then for the linker). The arguments could've been stored as consecutive C-strings in the archive metadata member. No parsing needed.
2. Make -L search paths registered in the static library scoped to the library only, like runpath (or maybe inherited like rpath). The plugin handler of bfd registers global search paths in at lowest priority. So I could not get it to work previously cause some system directory had a libg.a, which came before my specified -L path among deps. And even worse, dependency -L flags for libf.a could influence search behavior of the next -lg specified on the command line.

Let's see if anything useful comes out of https://sourceware.org/pipermail/binutils/2024-June/134962.html

[rui314]

-L looks odd to me in the first place because, if you know the path in which a library exists when you create an archive file, you can specify the library as a full or a relative path instead of just -lfoo. I.e. /path/to/libfoo.so. So I think the -L should not present in the __.LIBDEP.

[haampie]

I agree to some extent, but potentially -L and -l separated could make the linker still attempt to link the relevant deps even if the library moved to a different system where paths are different (and users would have to put -L on the link line regardless). Otherwise it would be a linker failure cause the user doesn't have the libs in the exact same absolute paths.