Como executar um software que requer uma versão de biblioteca legada?

1

Eu tenho um aplicativo antigo que requer uma versão antiga do OpenCV (< = 2.4.9) e trava em versões mais recentes (o OpenCV já descartou parcialmente o suporte para a API C desde 2.5). Eu costumava usar apenas a distribuição antiga e blacklist opencv no entanto como essa versão não é mais suportada em todos - eu fui forçado a atualizar. A versão atual do openCV é 3.1.

Posso usar contêineres para isso? Eu só preciso dessa biblioteca para ser velha. Eu posso compilar o antigo OpenCV, mas estou um pouco preocupado com o suporte ao X - é um aplicativo gráfico que obviamente usa câmera. Ou talvez exista uma solução melhor?

    
por Lapsio 07.04.2017 / 22:30

1 resposta

2

O problema de apenas substituir o OpenVZ é que muitas bibliotecas dependem umas das outras (o antigo problema do "Inferno da DLL"). Algumas bibliotecas dependem do OpenVZ, e o OpenVZ depende de outras bibliotecas, que dependem ainda de mais bibliotecas, etc.

Dependendo de quantos anos você precisa ir, você pode evitar o uso de contêineres trazendo um "subconjunto coeso" de bibliotecas antigas para um diretório e, em seguida, usar a variável de ambiente LD_LIBRARY_PATH para apontar o carregador dinâmico para suas antigas bibliotecas. / p>

Isso geralmente funciona bem se a versão do libstdc ++ e libc no seu sistema host (em / lib ou / usr / lib) for ABI-compatível com a versão que foi usada para compilar e vincular seu versão antiga do OpenCV (e suas dependências). Infelizmente, ao contrário da ABI do kernel do Linux, a ABI da libc muda ocasionalmente, e a ABI da libstdc ++ muda com frequência.

Então, pegar um antigo binário do OpenCV com a versão que você precisa viria com aproximadamente esse processo:

  • Tente apenas a antiga biblioteca OpenCV no diretório LD_LIBRARY_PATH. Se não funcionar, você obterá erros sobre a falta de bibliotecas (assumindo que as dependências fazem o controle de versão corretamente); vá pegar as bibliotecas perdidas e coloque-as no mesmo diretório que o antigo OpenCV. Repita até desaparecer os erros da biblioteca.
  • Se você chegar a um ponto em que obtiver erros de pesquisa de símbolos no libstdc ++ ou libc, ou reclamações sobre a versão glibc incorreta, estará em um fluxo sem remo e suas únicas soluções (além da virtualização e instalação de um sistema operacional antigo versão) são ...

Flatpak

link - um formato de empacotamento de aplicativo que inclui todas as bibliotecas de dependências:)

e

Contêineres

Os contêineres são uma boa abordagem, porque as soluções de contêiner good , como LXC e LXD, isolam completamente o convidado e até mesmo permitem que o convidado execute seu próprio PID 1 (daemon de inicialização). Basicamente, para iniciar qualquer processo no Linux, certas coisas devem ser compatíveis entre o que você já está executando e o que você está iniciando, porque, por exemplo, o carregador dinâmico (libdl) tem que ser capaz de carregar as bibliotecas compartilhadas. Mas os contêineres têm uma maneira de isolar completamente isso, então você pode usar versões incompatíveis de libc, libdl e libstdc ++ no mesmo kernel do host.

Eu recomendaria o LXD se você executasse o Ubuntu > = 16.04, ou o OpenVZ se você executasse um sistema host Debian antigo ou CentOS / RHEL. Infelizmente, o LXD não é muito fácil de configurar em distribuições que não sejam do Ubuntu, e o OpenVZ (ainda) não suporta as distribuições mais recentes.

O bom do kernel do Linux é que, com algumas exceções para interfaces específicas de driver (como o Direct Rendering Manager), a ABI do kernel do Linux é estável por um longo tempo. Isso significa:

  • Os "userspaces" antigos (tudo o que é executado sobre o kernel e não dentro dele) devem funcionar em kernels bem mais novos.
  • Novos espaços de usuário devem funcionar em kernels muito mais antigos.

Na prática, o que isso significa é que, a menos que você esteja usando drivers gráficos 3D ou outros tipos de hardware especializado em seu contêiner, ele deve "Just Work", independentemente da diferença de idade entre o sistema contêiner e o host kernel até um certo limite; o software compilado para o kernel Linux mais antigo que o 2.6.9 geralmente não funcionará em um kernel moderno, e mais antigo que o 2.6.0 definitivamente não funcionará.

Isso deixa uma gradação de "mínimo esforço necessário" para executar bibliotecas mais antigas (ou binários que dependem de bibliotecas mais antigas), dependendo de quão antigo e quão profundo é o velhice:

  • Mínimo: Solte a versão antiga da biblioteca em um diretório, defina LD_LIBRARY_PATH e pronto.
  • Típica (isso é usado com muitos jogos e programas proprietários): Solte a versão antiga da biblioteca e todas as suas dependências exceto a libc, defina LD_LIBRARY_PATH e pronto.
  • Substituição extensiva da biblioteca (com bugs; pode não funcionar): elimine a versão antiga da biblioteca, libstdc ++, libc, libdl e todas as suas dependências em um diretório, defina LD_LIBRARY_PATH e pronto.
  • Contêineres: Instale um sistema básico completo para outro SO mais antigo sobre o kernel do host sem executar virtualização (você ainda está executando apenas uma cópia do kernel do Linux). Rápido , mas ocupa vários espaços em disco. Extremamente compatível com praticamente qualquer coisa que você possa usar (incluindo distribuições antigas).
  • Máquinas virtuais: podem executar qualquer sistema operacional, mesmo que não seja Linux, e a compatibilidade não é uma preocupação, desde que o software do sistema operacional convidado seja executado na mesma CPU do seu hardware.
por 07.04.2017 / 23:37