ld-2.9.1: REQ: better support for relative link script paths
Hi!
For the binutils people: debian-hurd is a list of people who are
creating an easy-to-install version of the complete GNU system. A lot
of us are using cross-compilers right now, and the following is taken
from a discussion that we were having.
On the Hurd, libc.so (from glibc-pre2.1) is a linker script that looks
like this:
----------------------------------------------------------------------
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
GROUP ( /lib/libc.so.0.2 /lib/libcrt_nonshared.a )
----------------------------------------------------------------------
This has caused problems for people who cross-compile, because even
though the runtime system uses /lib, we have it mounted as /gnu/lib
during compilation. So, /lib/libc.so.0.2 is
>>>>> Marcus Brinkmann writes:
MB> I am just curious: Why was the path hardcoded at all? The old
MB> version of the file seems to work as well. I include it here for
MB> your reference.
[...]
The following would *seem* like the right thing:
GROUP ( libc.so.0.2 libcrt_nonshared.a )
but it has a subtle problem. Most of the time it works, but GNU ld
searches the current working directory *before* the library path, so
if you touch a file called `libc.so.0.2' in the current directory,
everything breaks. Try it for yourself.
This is why Ulrich changed glibc to use an absolute path.
However, I think that an absolute path is just as bad: you have to
write a wrapper or modify a script every time you put the libraries
into a new directory.
The ideal solution, IMO, would be to change GNU ld so that a certain
notation can specify a file that is only found in the same directory
as the linker script. The current behaviour (search the CWD, then the
library search path) might be useful sometimes, but I doubt it is what
most people want when they use unqualified filenames in their scripts.
I would greatly appreciate anybody's help with this issue, including
suggestions for notation, or better yet, patches to GNU ld.
Thanks,
--
Gordon Matzigkeit <gord@fig.org> //\ I'm a FIG (http://www.fig.org/)
Lovers of freedom, unite! \// I use GNU (http://www.gnu.org/)
[Unfortunately, www.fig.org is broken. Please stay tuned for details.]
Reply to: