Comentário sobre o YUM & deps
O YUM faz isso. Mas é tão bom quanto o RPM especifica. Nesse caso, seu RPM informa que ele funcionará com qualquer GLIBC > 2.13 mas foi claramente construído com uma versão específica do GLIBC, e só funcionará se os símbolos GCC apropriados estiverem disponíveis no sistema:
$ rpm -qpR trillian-6.1.0.5-1.fc25.x86_64.rpm
atkmm >= 2.22.0
cairo >= 1.12.0
cairomm >= 1.10.0
gdk-pixbuf2 >= 2.26.0
glib2 >= 2.30.0
glibc >= 2.13
glibmm24 >= 2.32.0
gtk3 >= 3.4.0
gtkmm30 >= 3.4.0
libX11 >= 1.5.0
libXScrnSaver >= 1.2.0
libnotify >= 0.7.5
librsvg2-tools >= 2.36.0
libsigc++20 >= 2.2.10
libzip >= 0.10.0
openssl-libs >= 1:1.0.1
pango >= 1.30.0
pangomm >= 2.28.0
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
zlib >= 1.2.0
Você pode usar rpm -qpR <rpm> para determinar quais dependências são necessárias.
Mais sobre o seu problema
O ponto central do seu problema é que você está tentando usar um pacote que foi criado usando uma versão diferente do compilador do GCC e quais bibliotecas de tempo de execução estão realmente disponíveis em seu sistema operacional.
No seu caso você está no CentOS 7.xe você realmente não pode misturar RPMs através do Fedora & CentOS assim, ou pelo menos você não deveria.
Se você observar qual pacote possui essa biblioteca compartilhada:
$ rpm -qf /lib64/libstdc++.so.6
libstdc++-4.8.5-28.el7_5.1.x86_64
Você também pode investigar a própria biblioteca compartilhada para ver quais símbolos do GCC ela suporta:
$ nm -D /lib64/libstdc++.so.6 | grep -i GLIBC | head -5
0000000000000000 A GLIBCXX_3.4
0000000000000000 A GLIBCXX_3.4.1
0000000000000000 A GLIBCXX_3.4.10
0000000000000000 A GLIBCXX_3.4.11
0000000000000000 A GLIBCXX_3.4.12
E, finalmente, olhe para ver se inclui os que os binários deste RPM estão procurando:
$ nm -D /lib64/libstdc++.so.6 | grep -iE '3\.4\.20|3\.4\.21'
$
Sem surpresas, essa biblioteca .so não inclui os símbolos para nenhuma dessas versões do GCC, daí o erro.
O que fazer?
As formas típicas de lidar com isso são:
- Obtenha um binário criado contra as definições de símbolo do seu GCC
-
Obtenha apenas a biblioteca
libstdc++.so.6de alguma outra ferramenta (muitos aplicativos optam por incluir bibliotecas para implantação / instalação / instalação mais fáceis) e aponte para ela por meio deLD_LIBRARY_PATH. Você normalmente faz assim:$ LD_LIBRARY_PATH=/path/to/lib trillian -
Execute o aplicativo em uma VM
- Execute o aplicativo em um contêiner do Docker
- Obtenha uma versão do RPM que tenha binários criados usando símbolos consistentes com a configuração do GCC do sistema operacional.
Dadas as semelhanças entre o Fedora & CentOS Eu tive um bom sucesso com muitos dos itens acima. Você poderia tentar # 5 e tentar um dos mais antigos RPMs do Fedora em seu site para ver se ele foi construído com a versão do CentOS dos símbolos do GCC.