objetos compartilhados portátil?

Question

É possível usar arquivos de objetos compartilhados de uma forma portátil como DLLs no Windows ??

Eu estou querendo saber se existe uma maneira que eu poderia fornecer uma biblioteca compilada, pronta para uso, para Linux. Como da mesma forma que você pode compilar uma DLL no Windows e pode ser usado em qualquer outra do Windows (ok, não qualquer outro, mas na maioria deles que puder).

Isso é possível no Linux?

EDIT:
Acabei de acordar e ler as respostas. Há alguns muito bons.
Eu não estou tentando esconder o código-fonte. Eu só quero fornecer uma biblioteca já compilado-e-ready-to-use, assim os usuários sem experiência na necessidade de compilação não faça para fazê-lo eles mesmos.
Daí a idéia é fornecer um arquivo .so que funciona em tantos Linuxes diferentes quanto possível.
A biblioteca é escrito em C ++, usando bibliotecas STL e Boost.

Answer 1

I altamente altamente recomendamos o uso da LSB aplicativo verificador / biblioteca. Sua indo dizer-lhe rapidamente se:

• Estão usando extensões que não estão disponíveis em algumas distros
• Apresente festança-ismos em seus scripts de instalação
• Use syscalls que não estão disponíveis em todos os kernels recentes
• depende de bibliotecas não-padrão (ele vai dizer o que distros falta deles)
• E muito, sobre muitas outras muito boas verificações

Você pode obter mais informações aqui , bem como baixar a ferramenta. Seu fácil de executar .. apenas untar-lo, executar um script Perl e aponte o navegador para localhost .. o resto é impulsionado browser.

Usando a ferramenta, você pode facilmente obter sua biblioteca / app LSB certificado (para ambas as versões) e fazer o trabalho do acondicionador distro muito mais fácil.

Além disso, basta usar algo como libtool (ou similar) para se certificar de sua biblioteca está instalado corretamente, fornecer um objeto estático para as pessoas que não querem ligação contra o DSO (isso vai levar tempo para a sua biblioteca para aparecer na maioria das distribuições, assim que escrever um programa portátil, não posso contar com ele estando presente) e comentar a sua interface pública bem.

Para bibliotecas, acho que Doxygen funciona melhor. A documentação é muito importante, certamente influencia a minha escolha de biblioteca para uso para qualquer determinada tarefa.

Realmente, mais uma vez, veja o verificador de aplicativo, a sua vai dar-lhe relatórios de problemas de portabilidade que levariam um ano de ter a biblioteca para fora no selvagem para obter de outra forma.

Finalmente, tente fazer sua biblioteca fácil de cair 'em árvore', então eu não tenho que ligar estaticamente contra ela. Como eu disse, pode levar um par de anos antes de se tornar comum na maioria das distribuições. Seu muito mais fácil para mim basta pegar o seu código, solte-o em src / lib e usá-lo, e até se a biblioteca é comum. E, por favor, por favor .. me dê testes de unidade, TAP (Protocolo nada teste) é uma boa e maneira portátil para fazer isso. Se eu cortar sua biblioteca, eu preciso saber (rapidamente) se eu quebrou, especialmente quando modificá-lo em árvore ou en situ (se o DSO existe).

Answer 2

Se você gostaria de ajudar seus usuários, dando-lhes o código compilado, a melhor maneira que eu sei é dar-lhes uma documentação binária + estaticamente ligado como eles podem executar o binário. (Isto é, possivelmente, além de dar o código-fonte para eles.) A maioria dos binários ligados estaticamente trabalhar na maioria das distribuições Linux da mesma arquitetura (+ 32-bit (x86) binários estaticamente ligado de trabalho em 64 bits (amd64)). Não é à toa Skype fornece um download Linux estaticamente ligado.

De volta à sua pergunta biblioteca. Mesmo se você é um especialista em escrever bibliotecas compartilhadas no Linux, e você tomar o seu tempo para minimizar as dependências para que a sua biblioteca compartilhada iria trabalhar em diferentes distribuições Linux, incluindo versões antigas e novas, não há nenhuma maneira de garantir que ele vai trabalhar no futuro (digamos, 2 anos). Você provavelmente vai acabar mantendo o arquivo .so, ou seja, fazendo pequenas modificações repetidas vezes para que o arquivo .so se tornar compatível com as versões mais recentes de distribuições Linux. Esta não é divertido fazer por um longo tempo, e diminui sua produtividade substancialmente: o tempo que você gasta em manter a compatibilidade biblioteca teria sido muito melhor gasto em por exemplo melhorar a funcionalidade, eficiência, segurança etc. do software.

Observe também que é muito fácil para perturbar seus usuários, fornecendo uma biblioteca em .so forma, que não funciona em seu sistema. (E você não tem a superpotência para torná-lo trabalhar em todas sistemas Linux, assim que esta situação é inevitável.) Você fornecer 32-bit e 64-bit, bem como, incluindo x86, PowerPC, ARM etc.? Se o arquivo .so funciona somente no Debian, Ubuntu e Red Hat (porque você não tem tempo tempo para a porta do arquivo para mais distribuições), você provavelmente perturbar o seu SUSE e usuários do Gentoo (e mais).

Answer 3

Idealmente, você vai querer usar GNU autoconf , automake , e libtool para criar scripts de configuração e fazer, em seguida, distribuir a biblioteca como origem com o configure gerados e arquivos Makefile.in.

Aqui está um livro on-line sobre eles.

./configure; make; make install é bastante normal no Linux.

A raiz do problema é que o Linux roda em muitos processadores diferentes. Você não pode apenas contar com o processador que suporte x86 instruções como o Windows faz. (Para a maioria das versões: Itanium (XP e mais recentes) e Alpha (NT 4.0) são as exceções)

Answer 4

Assim, a pergunta é, como desenvolver bibliotecas compartilhadas para Linux? Você poderia dar uma olhada este tutorial ou o pogram Biblioteca Howto .

Answer 5

Eu sei o que você está pedindo. Para o Windows, MSFT fez cuidadosamente as DLLs todos compatíveis, para que seus DLLs são geralmente compatível para quase todas as versões do Windows, é por isso que você chamá-lo de "portátil".

Infelizmente, no Linux há demasiadas variações (e todo mundo está pensando para ser "diferente" para ganhar dinheiro) para que você não pode obter mesmos benefícios que o Windows, e é por isso que temos muita mesmos pacotes compilados para distribuições diferentes, versão distro, tipo de CPU, ...

Alguns dizem que o problema é causado pela arquitetura (CPU), mas não é. Mesmo no mesmo arco, ainda há diferentes entre distribuições. Uma vez que você realmente tentou lançar um pacote binário, você sabe o quanto é difícil - mesmo tempo de execução C dependência biblioteca é difícil de manter. Linux OS falta muita coisa por isso quase todos os serviços envolve questão de dependência.

Normalmente, você só pode construir algum binário que é compatível com alguma distribuição (ou, várias distribuições se você tiver sorte). É por isso que liberando programas Linux em binário sempre asneira, a não ser obrigado a alguma distro como o Ubuntu, Debian, ou RH.

Answer 6

Basta colocar um arquivo .so em / usr / lib pode trabalho, mas é provável que estragar o esquema que a sua distro tem para gerir bibliotecas.

Dê uma olhada no Linux Standard Base -. Isso é a coisa mais próxima que você vai encontrar para uma plataforma comum entre distros linux

http://www.linuxfoundation.org/collaborate/workgroups/lsb

O que você está tentando realizar?

Answer 7

A resposta de Tinkertim no local. Vou acrescentar que é importante para entender e planejar mudanças para do gcc ABI . As coisas têm sido bastante estável recentemente e acho que todas as grandes distros estão no gcc 4.3.2 ou assim. No entanto, a cada poucos anos alguns alteração à ABI (especialmente o C ++ pedaços relacionados) parece para causar o caos, pelo menos para aqueles que querem lançar binários cross-distro e para usuários que tenham se acostumado a pegar pacotes de outras distros que eles realmente executar e encontrar eles funcionam. Enquanto uma dessas transições está acontecendo (todas as distros atualizar em seu próprio ritmo) que você quer idealmente para liberar libs com ABIs apoiando toda a gama de versões gcc em uso por seus usuários.