Bug 16341 - relative paths in ld.script break gold linker
Summary: relative paths in ld.script break gold linker
Status: RESOLVED DUPLICATE of bug 11182
Alias: None
Product: binutils
Classification: Unclassified
Component: gold (show other bugs)
Version: 2.24
: P2 normal
Target Milestone: ---
Assignee: Cary Coutant
Depends on:
Reported: 2013-12-18 10:49 UTC by gidyn
Modified: 2015-06-08 00:53 UTC (History)
3 users (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description gidyn 2013-12-18 10:49:47 UTC
Relative paths in the link script trigger "cannot find" errors. See the Fedora bug tracker https://bugzilla.redhat.com/show_bug.cgi?id=635935 for an example.
Comment 1 Cary Coutant 2013-12-18 18:09:32 UTC
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.
Comment 2 Markus Trippelsdorf 2014-03-04 07:48:12 UTC
I ran into this issue today when trying to build GHC 7.8.1-RC2:

markus@x4 ghc- % cat /tmp/ghc9794_0/ghc9794_4.ldscript
INPUT(libraries/ghc-prim/dist-install/build/GHC/Magic_o_split/Magic__1.o libraries/ghc-prim/dist-install/build/GHC/Magic_o_split/Magic__2.o libraries/ghc-prim/dist-install/build/GHC/Magic_o_split/Magic__3.o)

markus@x4 ghc- % /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -nostdlib -Wl,-r -nodefaultlibs '-Wl,--build-id=none' -o libraries/ghc-prim/dist-install/build/GHC/Magic.o /tmp/ghc9794_0/ghc9794_4.ldscript
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Magic_o_split/Magic__1.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Magic_o_split/Magic__2.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Magic_o_split/Magic__3.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: internal error in target, at /var/tmp/portage/sys-devel/binutils-9999/work/binutils/gold/parameters.h:105
collect2: error: ld returned 1 exit status

ld.bfd is fine.
Comment 3 Cary Coutant 2015-06-08 00:53:39 UTC
This is the same issue as PR 11182.

*** This bug has been marked as a duplicate of bug 11182 ***