On Tue, 2010-01-12 at 09:01 +0000, Andrew Suffield wrote:
> > This is a main linking to libfoo.so via rpath but overridden to link to
> > a separate ./bar/libfoo.so that exports a different implementation of
> > extern int foo();
>
> asuffi...@cyclone:~/tmp$ echo 'int foo = 42;' > foo42.c
> asuffi...@cyclone:~/tmp$ echo 'int foo = 43;' > foo43.c
> asuffi...@cyclone:~/tmp$ gcc -shared -o libfoo.so foo42.c
> asuffi...@cyclone:~/tmp$ gcc -shared -o bar/libfoo.so foo43.c
> asuffi...@cyclone:~/tmp$ printf '#include <stdio.h>\nextern int foo; int
> main(void){printf("%%d\\n",foo);}\n' > main.c
> asuffi...@cyclone:~/tmp$ gcc -o main main.c libfoo.so -Wl,-rpath .
> asuffi...@cyclone:~/tmp$ ./main
> 42
> asuffi...@cyclone:~/tmp$ LD_LIBRARY_PATH=bar ./main
> 42
I'm with you up to this point. I get 43.
> asuffi...@cyclone:~/tmp$ LD_DEBUG=libs LD_LIBRARY_PATH=bar ./main
> 20013: find library=libfoo.so [0]; searching
> 20013: search path=./tls/x86_64:./tls:./x86_64:. (RPATH
> from file ./main)
> 20013: trying file=./tls/x86_64/libfoo.so
> 20013: trying file=./tls/libfoo.so
> 20013: trying file=./x86_64/libfoo.so
> 20013: trying file=./libfoo.so
> 20013:
$ LD_DEBUG=libs LD_LIBRARY_PATH=bar ./main
4295: find library=libfoo.so [0]; searching
4295: search path=bar/tls/x86_64:bar/tls:bar/x86_64:bar
(LD_LIBRARY_PATH)
4295: trying file=bar/tls/x86_64/libfoo.so
4295: trying file=bar/tls/libfoo.so
4295: trying file=bar/x86_64/libfoo.so
4295: trying file=bar/libfoo.so
Check readelf -d main, I get
0x000000000000000f (RPATH) Library rpath: [.]
0x000000000000001d (RUNPATH) Library runpath: [.]
I'm guessing you've got just the RPATH and not the RUNPATH.
> Are you perhaps not on a glibc system?
I am on a glibc system (gentoo).
> The manpage you quoted is not the one normally found there (which also
> happens to be wrong, sigh).
I'm using man-pages-3.22 which is built from the upstream package
distributed from http://www.kernel.org/pub/linux/docs/manpages/Archive/
> I did say that this behaviour is totally non-portable. glibc follows
> the ELF specification and, approximately, Solaris, but most other
> things do not.
> > Is your concern about old .so libs that have an DT_RPATH but no
> > DT_RUNPATH entry and thus invoke the old behaviour?
>
> ghc uses DT_RPATH with no DT_RUNPATH, because it relies on dlopen()
> for addDLL() to work [see previous mail re: DT_RUNPATH does not work
> with dlopen(), by design]
>
> I am not sure why you think there are any 'new' libraries that use
> DT_RUNPATH. It's a little-known and rarely-used feature; the effort to
> replace DT_RPATH is widely regarded to have been a failure.
Our systems seem to be completely different! :-) What version of GNU
binutils are you using, on what distro?
I can't make an old-style ELF that uses just DT_RPATH with no
DT_RUNPATH. I assumed this was the default in binutils for ages. Are
other linux systems set up so that you have to use ld --enable-new-dtags
to get this behaviour?
So I'm guessing that your system is using just DT_RPATH by default and
not generating ELF libs with DT_RUNPATH. Can you try your above script
with foo.c, main etc but link main with -Wl,--enable-new-dtags or some
similar trick to get ld to use DT_RUNPATH rather than the DT_RPATH.
Duncan
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
