Runtime-Linker ignoriert RPATH in ausführbare Datei auf solaris

Question

Ich versuche zu kompilieren samtools auf einem Solaris-Server, auf dem ich habe keine Wurzel. Samtools hängt von zlib. Das System zlib auf dieser Maschine ist nicht mit Unterstützung für große Dateien kompiliert, so samtools gegen diese Version kompiliert hat die erwartete Wirkung: samtools nur kleine Dateien. Ich muß es in der Lage sein, große Dateien zu handhaben. Glücklicherweise gibt es eine Version von zlib durch den Admin in /usr/local/apps/zlib-1.2.5/ mit Unterstützung großer Dateien kompiliert. Ich kann durch Zugabe von -R /usr/local/apps/zlib-1.2.5/lib zu CFLAGS gegen diese kompilieren, aber das scheint nicht zu funktionieren. Die Symptome sind wie folgt:

Wenn ich versuche, samtools zu laufen, stürzt mit diesem Fehler:

ld.so.1: samtools: fatal: relocation error: file samtools: symbol gzopen64: referenced symbol not found

Wenn ich /usr/local/apps/zlib-1.2.5/ zu LD_LIBRARY_PATH hinzufügen, dann samtools funktioniert.

Die Analyse samtools mit ldd und readelf ergibt folgendes:

$ ldd -r samtools
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        libm.so.2 =>     /usr/lib/libm.so.2
        libcurses.so.1 =>        /usr/lib/libcurses.so.1
        libz.so =>       /usr/lib/libz.so
        libc.so.1 =>     /usr/lib/libc.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libmd.so.1 =>    /usr/lib/libmd.so.1
        libscf.so.1 =>   /usr/lib/libscf.so.1
        libdoor.so.1 =>  /usr/lib/libdoor.so.1
        libuutil.so.1 =>         /usr/lib/libuutil.so.1
        libgen.so.1 =>   /usr/lib/libgen.so.1
        symbol not found: gzopen64              (samtools)

$ ldd -s samtools

   ...(snip)...

   find object=libz.so; required by samtools
    search path=/usr/lib:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib  (LD_LIBRARY_PATH)
    trying path=/usr/lib/libz.so
        libz.so =>       /usr/lib/libz.so

   ...(snip)...

$ readelf -d samtools | grep RPATH
 0x0000000f (RPATH)                      Library rpath: [/usr/local/apps/zlib-1.2.5/lib:/usr/local/apps/gcc-4.5.1/lib]

So /usr/local/apps/zlib-1.2.5/lib ist eindeutig in der RPATH ist binär, was ich verstehe, sollte für gemeinsam genutzte Bibliotheken zur Laufzeit gesucht werden. Allerdings ldd -s zeigt, dass dieses Verzeichnis wird nie gesucht. Das Hinzufügen dieses Pfades zu LD_LIBRARY_PATH und wieder laufen die LDD-Befehle hat den erwarteten Effekt. Das Verzeichnis durchsucht wird und die richtige Version von libz gefunden wird

So wie ich samtools zwingen kann, ohne die Verwendung von LD_LIBRARY_PATH in /usr/local/apps/zlib-1.2.5/lib zur Laufzeit suchen?

---

Edit: Die Dokumentation hier würde darauf hindeuten, dass die -R Option die richtige Sache zu tun. Aber es funktioniert nicht.

Answer 1

Ich bin keineswegs ein Solaris-Experte, aber diese Zeile:

find object=libz.so; required by samtools
 search path=/usr/lib:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib  (LD_LIBRARY_PATH)

scheint mir, um anzuzeigen, dass LD_LIBRARY_PATH bereits gesetzt ist, und der /usr/lib Weg in ihrem Vorrang vor allen Laufzeitlinker Wegen zu gehen. Können Sie ungesetzt LD_LIBRARY_PATH, wenn es in der Tat vorhanden ist, und sehen, ob das löst es?