Compile Python 3.1.1 com --enable-shared

Question

Esta é uma pergunta em duas partes ... O contexto da questão é obter uma boa compilação 3.1.1 do Python para usar com a construção e execução do mod_wsgi. Consulte este documento para obter mais informações sobre por que uma biblioteca compartilhada é uma boa ideia.

Quais são as ramificações da criação do Python com --enable-shared?

Eu observo que quando eu o construo SEM --enable-shared, o binário python é ~ 16MB

-rwxr-xr-x 2 root root 1638104 Aug 17 12:29 python3.1

Com --enable-shared, o binário do python é 15K.

-rwxr-xr-x 2 root root   15860 Oct  5 22:34 python3.1

Em geral, o que isso faz com operações "normais" de python? Todos os scripts ainda serão executados da mesma forma? Qualquer impacto no desempenho? Você pode, ou é desejável, ter ambos (compartilhados e estáticos)?

Todas as ideias sobre como resolver este erro de forma clara?

Observação: construído em uma instalação limpa do RHEL 5.3 de 64 bits.

Depois de criar o Python 3.1.1 com ./configure --enable-shared , recebo este erro:

[root@test ~]# python3
python3: error while loading shared libraries: 
libpython3.1.so.1.0: cannot open shared object file: No such file or directory

Eu resolvi isso colocando este link simbólico:

/usr/lib64/libpython3.1.so.1.0 -> /usr/local/lib/libpython3.1.so.1.0

Que parece bastante hackish ... Existem opções de ./configure que podem ser passadas para curar isto?

-

Obrigado!

    

Answer 1

Este é provavelmente um para superuser.com mas ok, eu vou morder.

What are the ramifications of building Python with --enable-shared?

Você obtém um binário que usa o carregador dinâmico para vincular-se às bibliotecas necessárias, nada de errado com isso. Quando qualquer uma das bibliotecas das quais seu binário depende for atualizada, a próxima invocação desse binário se beneficia, em vez da próxima compilação.

In general, what does that do to "normal" operations of python?

Nada.

Will all scripts still run the same?

Sim.

Any performance impact?

Se a desova de processos python rapidamente é sua única preocupação, a vinculação estática é um pouco mais rápida.

Can you, or is it desirable, to have both (shared and static)?

Claro que você pode, mas um binário dinâmico faz bem, não há necessidade de binários estáticos, a menos que você saiba que precisa.

Any ideas on how to solve this error cleanly?

Edite /etc/ld.so.conf, adicione "/ usr / local / lib" em uma linha própria, execute ldconfig

Are there ./configure options that can be passed to cure this?

Apenas supondo ... --prefix = / usr

    

Answer 2

Eu mesmo me deparei com esse problema, em um sistema Fedora de 64 bits, e encontrei uma resposta não tanto, mas pelo menos uma explicação para mim:

Este bug do Python existe desde 2003, e ainda se aplica ao 3.1: Existe um sinal --libdir para configure que deve ser capaz de definir o diretório da biblioteca, mas na realidade não faz nada; as bibliotecas do Python sempre serão instaladas em " PREFIX/lib ". O bug tem alguns desenvolvedores informando por que esse é o caso (por enquanto). Então, no meu caso para o Fedora, rodando:

./configure --enable-shared --prefix=/usr

Eu tive que correr

ln -s /usr/lib/libpython3.1.so.1.0 /usr/lib64/libpython3.1.so.1.0

após a instalação para que funcione. Então, sim, é um pouco hack-ish, mas é assim que a compilação do Python funciona por enquanto.

    

Answer 3

Para quem voltar a esta, esta é a solução correta:

Edite o /etc/ld.so.conf ou crie algo em /etc/ld.so.conf.d/ para adicionar / usr / local / lib e / usr / local / lib64. Em seguida, execute ldconfig.