Como fazer com que $ ORIGIN no RPATH não siga links simbólicos?

Question

Eu tenho um executável app , que depende de uma biblioteca libbar.so e carrega via RPATH com $ORIGIN assim:

$ readelf -d app

Dynamic section at offset 0xe08 contains 26 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libbar.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/lib/]

Seria bom executá-lo na estrutura de diretório apropriada, feita com links simbólicos para o executável e o libbar.so :

$ ls -R
.:
app@  lib/

./lib:
libbar.so@

- mas o vinculador segue links simbólicos para o arquivo original do executável, define $ORIGIN para o diretório do arquivo executável e resolve os caminhos de dependência a partir dele. É possível fazê-lo não fazer isso? Para que, em busca de arquivos lib, os links simbólicos sejam tratados como arquivos reais do sistema de arquivos ("end-points" da pesquisa).

Além disso, alguns argumentos para esse problema:

1. É conveniente ter binários configurados para procurar por dependências em alguns diretórios relacionais , por exemplo, no $ORIGIN/ de um binário em si e também em $ORIGIN/appname_dependencies/ (portanto que se pode simplesmente copiar o binário e suas dependências em um diretório e executá-lo, mas também ter um fall-back para uma configuração mais complicada com múltiplas versões do mesmo binário no sistema).

2. Devido ao requisito de vários caminhos de pesquisa de dependência, RPATH é o método de pesquisa para usar : um nome de dependência "cortado" ( NEEDED Shared library: [./libbar.so] ) define apenas 1 caminho de pesquisa . Além disso, por simplicidade, os caminhos de resolução de dependência devem estar no próprio binário.

3. É bom poder combinar todos os binários (o aplicativo e todas as suas dependências) no gráfico de dependência completo com links , em vez de copiar os arquivos. E os links simbólicos são mais resilientes que os hard links: eles se conectam entre os sistemas de arquivos. Na verdade, eu tenho esse problema em um ambiente acadêmico de um cluster Linux, onde um link rígido para o diretório pai não pode ser feito:

       $ ln ../afile 
       ln: creating hard link './afile' => '../afile': Invalid cross-device link
   

Answer 1

Se você realmente quiser misturar links simbólicos como esse, você poderia construir uma configuração como esta:

• mova seu executável para seu próprio diretório
• crie um link simbólico do local "normal" para o executável movido
• crie links simbólicos no diretório do executável para as bibliotecas compartilhadas que você deseja resolver