Can you install multiple versions of a single library?
Sim, definitivamente! O gerenciamento de pacotes sob * nix realmente torna isso muito simples. A única coisa que isso exigirá é que os pacotes não entrem em conflito (o que significa que alguns truques talvez precisem ser feitos pelo empacotador). Mas a sua verdadeira questão requer uma resposta mais aprofundada.
Would installing multiple versions of a library like this make software using the different versions work properly?
Talvez. Depende de como cada parte do software é vinculada à biblioteca necessária. Por exemplo, se você der uma olhada em /usr/lib , perceberá que a maioria das bibliotecas tem pelo menos dois arquivos diferentes nesse diretório ( libname.so e libname.so.#.#.# , em que # é um número). Você provavelmente notará que libname.so é geralmente um link simbólico para o segundo arquivo. Em geral, isso ocorre porque o software pode optar por vincular-se a uma versão específica de uma biblioteca ou por vincular a qualquer versão da biblioteca que não tenha versão (geralmente a versão mais recente).
Agora, se cada um dos componentes do software tiver requisitos específicos para cada versão da biblioteca, cada um deles poderá escolher diretamente a versão de que precisa (em vez de esperar que a biblioteca não versionada seja a desejada). Se este for o caso, então você provavelmente está em casa, e tudo que precisa fazer é ter as versões de bibliotecas diferentes instaladas corretamente. Se, no entanto, um desses softwares se vincular ao link não versionado, mas esperar que seja uma versão particular da biblioteca, ele funcionará a menos que o link não-versionado seja a versão que eles esperam.
Vamos usar um exemplo para demonstrar. No Arch Linux, duas versões de libpng são empacotadas oficialmente ( 1.2 e 1.6 ). Por acaso tenho ambos instalados.
$ ls -l /usr/lib | grep png
lrwxrwxrwx 1 root root 18 Mar 12 08:05 libpng12.so -> libpng12.so.0.51.0*
lrwxrwxrwx 1 root root 18 Mar 12 08:05 libpng12.so.0 -> libpng12.so.0.51.0*
-rwxr-xr-x 1 root root 168K Mar 12 08:05 libpng12.so.0.51.0*
lrwxrwxrwx 1 root root 19 Jun 27 19:53 libpng16.so -> libpng16.so.16.12.0*
lrwxrwxrwx 1 root root 19 Jun 27 19:53 libpng16.so.16 -> libpng16.so.16.12.0*
-rwxr-xr-x 1 root root 216K Jun 27 19:53 libpng16.so.16.12.0*
lrwxrwxrwx 1 root root 11 Jun 27 19:53 libpng.so -> libpng16.so*
Agora, olhando para este conjunto de arquivos, você notará que libpng.so (o link completamente não versionado) aponta para libpng16.so (um link com versão sem nenhum soname) que aponta para libpng.so.16.12.0 . Portanto, se um software escolher vincular a libpng.so , no meu sistema, ele será vinculado a libpng.so.16.12.0 ; e, esperançosamente, é isso que esse software espera. No entanto, se esse software realmente espera uma versão de 1.2 , haverá problemas.
A conclusão aqui é que, se você estiver empacotando o software, descubra quais são os requisitos rígidos que ele tem para as versões das bibliotecas e certifique-se de que, durante a etapa de compilação, ele esteja vinculado ao caminho certo. Se você é um desenvolvedor, a lição é que você deve tentar manter seu software atualizado com a versão mais recente de todas as bibliotecas às quais você está vinculado (para que você possa simplesmente vincular diretamente a libname.so e provavelmente ficar bem) ou descobrir de que coisas você depende e exigir links apenas para as versões da biblioteca que o suportam.