ld patch

[Andreas Hauser]

dillon wrote @ Fri, 26 Mar 2004 08:57:28 -0800 (PST):
> 
> :Slightly modified version attached, give it some testing.
> :
> :Joerg
> 
>     I think I got lost somewhere.  I'm a little confused over what issue
>     is being fixed here, could you explain it in a little more detail?

Sorry.

Say you link a programm against a library that itself
depends on another library. Like some newer libs in /usr/X11R6
depend on expat. Now the problem is, that expat is in /usr/local/lib
but all your programm gets as linker flags is -L/usr/X11R6/lib,
thus the linker can't find expat and fails (but rtld's
search path includes /usr/local/lib and it would run fine).

So you will only notice it when one of the libraries that you use
is outside the search path (which includes by default /lib /usr/lib).

The solution is usually using linker hints and/or DT_RPATH/DT_RUNPATH.

/etc/ld.so.conf is the config for the cache.
For the cache linux uses /etc/ld.so.cache while freebsd
uses /var/run/ld.so.hints and /var/run/ld-elf.so.hints as "cache".
Only that the cache on freebsd is not really used and only contains
the search pathes given in the config files. On linux it will also have
the actual .so pathes (e.g. /usr/lib/libfoo.so.1).

To get this behaviour freebsd patched the old binutils
and this is what this patch is about.
Without it ld didn't know as much as rtld did.

We could also consider using rpath, which would hardcode
a run path in the binaries/libraries into DT_RPATH or DT_RUNPATH
in the Dynamic Section of ELF ("objdump -p" will show it).
For X11 we could do this in DragonFly.cf.
(I'll try that tomorrow)

I now have a complete desktop system running with CCVER=gcc3
and the patch and it works just fine :-)

Btw. i would like to try amd64's 64Bit mode, how far is that?
(I know it will not even be complete for 1.0 but how far comes a boot
and what are the biggest problems and how to go about fixing those?)


Andy