Indicação de versão no nome do arquivo para uma biblioteca compartilhada

2

Estou desenvolvendo uma biblioteca compartilhada de várias plataformas agora, e estou um pouco confuso sobre a maneira correta como isso funciona no * nix. Meu plano para versões é bastante padrão, maiores interfaces de quebra, menores são adicionados a interfaces, mas permanecem compatíveis com versões mais antigas, e os números de correção são correções de bugs / melhorias que não tocam nas interfaces. Isso se traduz em menores devem incrementar a versão SO.

Portanto, o nome do arquivo da biblioteca é libNAME.so.X.Y.Z para a versão da biblioteca X.Y.Z e o nome da instalação é libNAME.so.X.Y . Meu problema aqui é que quando eu atualizo meu menor, eu gostaria que os executáveis vinculados existentes usassem a nova biblioteca (desde que sejam compatíveis com versões anteriores até X.0.0), mas os executáveis estão vinculados ao antigo libNAME.so.X.Y . Então, isso significa que eu preciso manter uma lista de links simbólicos para todas as versões menores abaixo do atual e atualizá-los todos para apontar para a nova biblioteca toda vez que eu atualizar minha biblioteca compartilhada?

    
por pat 27.09.2014 / 06:43

1 resposta

1

Os programas que usam sua biblioteca devem ser vinculados a libNAME.so , se quiserem a versão mais recente, com libNAME.so.X se quiserem a versão mais recente da versão principal X e com libNAME.so.X.Y se quiserem uma versão secundária específica.

Se você acabou de fornecer os links extras para libNAME.so , libNAME.so.X e libNAME.so.X.Y a libNAME.so.X.Y.Z , todos usarão a versão mais recente e você poderá atualizar esses links.

Suponha que a versão que você está instalando apresenta a versão menor, antes disso os links seriam (suponha que Y-1 seja o número antes de Y e z o nível de patch mais recente da série X.Y-1):

libNAME.so -> libNAME.so.X.Y-1.z
libNAME.so.X -> libNAME.so.X.Y-1.z
libNAME.so.X.Y-1 -> libNAME.so.X.Y-1.z

após a atualização ser instalada (Z provavelmente é 0, talvez 1):

libNAME.so -> libNAME.so.X.Y.Z
libNAME.so.X -> libNAME.so.X.Y.Z
libNAME.so.X.Y-1 -> libNAME.so.X.Y-1.z
libNAME.so.X.Y -> libNAME.so.X.Y.Z

qualquer programa que esteja explicitamente ligado para usar o X.Y-1 ainda encontrará o arquivo X.Y-1.z.

Seguindo este esquema, não há necessidade de atualizar nenhum dos links anteriores para além dos indicados e você pode determinar quais deles são se o seu número principal, menor ou de correção muda (1, 2, resp 3 links).

Costumava ser muito mais comum ter versões antigas de bibliotecas no seu sistema com esses links "intermediários". Mas o gerenciamento de pacotes geralmente elimina as versões antigas.¹

¹ Eu sempre gostei desta maneira de fazer as coisas, contando com os links para obter a versão mais recente, se não explicitamente pedindo um mais antigo. Na conferência Microsoft MFC (1994), onde as DLLs foram apresentadas como uma solução para bibliotecas compartilhadas, indiquei ao orador o problema de acessar versões mais antigas sem um esquema já comprovado. A frase "inferno da DLL" ainda tinha que ser inventada nesse ponto.

    
por 27.09.2014 / 07:23