O vinculador de tempo de execução ignora o RPath no executável no Solaris

Question

Estou tentando compilar Samtools em um servidor Solaris, onde não tenho root. Samtools depende do Zlib. O sistema Zlib nesta máquina não é compilado com suporte de arquivo grande; portanto, a compilação do SAMTOOLS contra esta versão tem o efeito esperado: o Samtools lida apenas com arquivos pequenos. Eu preciso que ele seja capaz de lidar com arquivos grandes. Felizmente, existe uma versão do Zlib compilada pelo admin in /usr/local/apps/zlib-1.2.5/ com suporte de arquivo grande. Eu posso compilar contra isso adicionando -R /usr/local/apps/zlib-1.2.5/lib para os cflags, mas isso parece não funcionar. Os sintomas são os seguintes:

Quando tento executar o Samtools, ele trava com este erro:

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

Se eu adicionar /usr/local/apps/zlib-1.2.5/ Para ld_library_path, então os samtools funcionam bem.

Analisar os samtools com LDD e o Readel produz o seguinte:

$ 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]

Então /usr/local/apps/zlib-1.2.5/lib está claramente no RPath do binário, o que eu entendo que deve ser pesquisado em tempo de execução por bibliotecas compartilhadas. No entanto, ldd -s mostra que este diretório nunca é pesquisado. Adicionando esse caminho a ld_library_path e re-executar os comandos LDD tem o efeito esperado: o diretório é pesquisado e a versão correta do libz é encontrada.

Então, como posso forçar os samtools a pesquisar /usr/local/apps/zlib-1.2.5/lib em tempo de execução sem usar ld_library_path?

---

Editar: a documentação aqui parece indicar que o -R A opção é a coisa correta a se fazer. Mas não funciona.

Answer 1

Não sou especialista em Solaris, mas esta linha:

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

parece indicar para mim que LD_LIBRARY_PATH já está definido, e o /usr/lib O caminho está tendo precedência sobre qualquer caminho do vinculador de tempo de execução. Você pode desmatar ld_library_path se estiver de fato presente e ver se isso resolve isso?