[Bug gold/16341] relative paths in ld.script break gold linker

[ccoutant at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16341

--- Comment #1 from Cary Coutant <ccoutant at google dot com> ---
Relative paths in the script file are interpreted relative to the directory
where the script file lives. Failing that, the normal library search path is
used.

The first part makes sense to me, and it seems that Gnu ld ought to at least do
that.

Using the library search path for a regular file name (i.e., not a -l option)
seems strange, but that's copied from Gnu ld.

Looking for files relative to the current directory doesn't seem like the right
thing to do, but I suppose it's a reasonable last choice.

Experimenting with Gnu ld...

I created a subdir/ld.script that contains "INPUT(sub1.o)", and linking with

   gcc -Wl,-t -L lib main.o -t subdir/ld.script

(a) With ./sub1.o, lib/sub1.o, and subdir/sub1.o, Gnu ld chooses ./sub1.o.

(b) With just lib/sub1.o and subdir/sub1.o, Gnu ld chooses lib/sub1.o.

(c) With just subdir/sub1.o, Gnu ld can't find sub1.o.

So the one place that makes the most sense to me is the one place that Gnu ld
doesn't look for the file!

If you add "-L ." to the link command, gold should find the file relative to
the current directory, and it will if the filename is just a path (with no
slashes). If the filename in the script is a relative path (e.g.,
"lib/sub1.o"), gold doesn't find it relative to the current directory. I think
that's a bug -- according the the --debug=files output, it tries
"./lib/sub1.o", but gold's directory search only works for bare filenames.

-- 
You are receiving this mail because:
You are on the CC list for the bug.