Dado um executável tal que:

>objdump -x someprog | grep c++
NEEDED               libstdc++.so.6

Desejo alterar o requisito para a versão completa (incluindo a versão secundária e o nível de patch):

>objdump -x someprog | grep c++
NEEDED               libstdc++.so.6.0.22

Conheço duas maneiras de fazer isso:

crie uma biblioteca fictícia conforme esta pergunta (Forçando ou impedindo o uso de uma versão secundária específica do libstdc ++)use patchelf

    >patchelf --add-needed libstdc++.so.6.0.22 someprog
    >objdump -x someprog | grep c++
    NEEDED               libstdc++.so.6
    NEEDED               libstdc++.so.6.0.22

(Eu não descobri uma linha de comando que funcione para --replace-needed)

Ambos parecem piratas para mim.Existe uma maneira de conseguir o mesmo no tempo de compilação ou link usando sinalizadores -Wl apropriados para o gcc?

Idealmente, quero evitar o uso de -nostdlib, pois isso exige que eu especifique não apenas o libstd ++, mas também o libc e tudo o mais para o qual desejo versões padrão.

Para uma biblioteca regular, apenas o link para a versão específica é suficiente para o libstdc ++, não é (ou melhor, suspeito que -stdlib substitua os nomes totalmente qualificados subsequentes que forneço).

fundo: Tenho executáveis que exigem uma versão posterior dolibstdc++ do que está instalado no sistema. Infelizmente, a versão instalada pode ser a mesma versão principal e, em caso afirmativo,ld felizmente usará a versão do sistema conforme ela corresponder àsoname libstdc++.so.6

Prefiro não vincular estaticamente, pois, na verdade, quero instalar muitos programas pequenos que compartilham o mesmo tempo de execução C ++ e isso incharia consideravelmente a instalação.

Algumas informações sobre o caminho de pesquisa da minha (the) biblioteca estão disponíveis aqui:

ld --verbose | grep SEARCH_DIR SEARCH_DIR ("/ usr / x86_64-redhat-linux / lib64"); SEARCH_DIR ("/ usr / lib64"); SEARCH_DIR ("/ usr / local / lib64"); SEARCH_DIR ("/ lib64"); SEARCH_DIR ("/ usr / x86_64-redhat-linux / lib"); SEARCH_DIR ("/ usr / local / lib"); SEARCH_DIR ("/ lib"); SEARCH_DIR ("/ usr / lib");

É claro no meu caso que / usr / lib64 está sendo pesquisado antes do RPATH do executável, que é:

>objdump -x /opt/foo/bin/bar | grep PATH
RPATH                $ORIGIN/../lib64/private:$ORIGIN/../lib64:$ORIGIN/

man ld.so sugere que a ordem de pesquisa deve ser:

Se uma dependência de biblioteca não contiver uma barra, ela será procurada na seguinte ordem:

   o  (ELF only) Using the directories specified in the DT_RPATH dynamic section attribute of the binary if present and DT_RUNPATH attribute does not exist.  Use of DT_RPATH is deprecated.

   o  Using the environment variable LD_LIBRARY_PATH.  Except if the executable is a set-user-ID/set-group-ID binary, in which case it is ignored.

   o  (ELF only) Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present.

   o  From the cache file /etc/ld.so.cache, which contains a compiled list of candidate libraries previously found in the augmented library path.  If, however, the binary was linked with the  -z  node‐
      flib linker option, libraries in the default library paths are skipped.  Libraries installed in hardware capability directories (see below) are preferred to other libraries.

   o  In the default path /lib, and then /usr/lib.  If the binary was linked with the -z nodeflib linker option, this step is skipped.

similarmentehttps://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf

Ambos parecem ser superados pelo uso real, mas na verdade não é esse o caso. o necessário é procurar links simbólicos:

>LD_LIBRARY_PATH= LD_DEBUG=libs ldd /opt/foo/bin/bar
 21720:     find library=libstdc++.so.6 [0]; searching
 21720:      search path=/opt/foo/bin/../lib64/private:/opt/foo/bin/../lib64:/opt/foo/bin                (RPATH from file /opt/foo/bin/bar)
 21720:       trying file=/opt/foo/bin/../lib64/private/libstdc++.so.6

Esta é uma interação com outra pergunta que eu tinhainstalar biblioteca importada compartilhada com os links necessários onde a sugestão era que os links não eram necessários. Eles claramenteestão necessário se você não especificar a versão semântica completa.