Como as bibliotecas / incluem o trabalho?

4

Estou tentando entender como as bibliotecas funcionam. Aqui estão algumas perguntas que tenho sobre isso:

  1. Eu fiz o download de um tarball e o extraí. Quando eu faço "./configure", ele procura em diretórios pré-definidos o que eu entendo para certos arquivos de biblioteca.

    O que isso faz então? Cria um makefile e o makefile contém os caminhos para essas bibliotecas?

    Depois eu faço "make", compila o código-fonte e codifica os locais das bibliotecas? Estou correto?

    Eu realmente não entendo se as bibliotecas são arquivos com caminhos pré-definidos ou o sistema operacional de alguma forma dá acesso às bibliotecas através de chamadas do sistema.

  2. Eu cumpri algo no meu computador do que movi-lo para um controle remoto servidor, o executável precisa de bibliotecas MySQL para funcionar, o servidor tem MySQL mas, por algum motivo, ao executar o arquivo, ele me diz "não é possível encontrar o libmysqlclient.so.16". Existe uma solução para isso? Existe uma maneira de saber onde tenta localizar esse arquivo ou dar outro caminho?

    Eu não posso compilá-lo no servidor, pois ele não tem compilador e eu não tenho acesso root para instalar pacotes.

  3. A última pergunta é se na sequência "./configure","make","make install" o comando "make install" é o único que realmente coloca arquivos fora do diretório em que esses arquivos residem?

    Se, por exemplo, o software for instalado em / usr / local / é o "make install" comandar o único que exigirá "sudo" antes?

    Deixe-me ver se entendi corretamente: "./configure" cria o Makefile de acordo com a localização de vários arquivos em seu sistema. "make" compila o código fonte de acordo com este makefile. E "make install" move os arquivos para o local apropriado.

Obrigado a todos que tiveram a paciência de ler minhas perguntas.

    
por fiftyeight 01.07.2011 / 02:59

2 respostas

3

configure gera um Makefile e geralmente outros arquivos, como config.cache . O conteúdo desses arquivos é baseado nas opções que você passa para configure e na observação de seu sistema. Por exemplo, muitos programas possuem componentes opcionais e configure procura as dependências de cada componente e gera um makefile que apenas constrói os componentes para os quais você tem todas as dependências.

Se você executar configure e, em seguida, alterar a configuração do sistema, deverá executar make distclean primeiro (se o programa seguir as convenções usuais), para remover o makefile e o cache configure . A execução de configure normalmente funciona quando você deseja passar argumentos diferentes, mas não quando suas observações em cache são armazenadas no sistema.

Com relação às bibliotecas, o estágio configure examina o que você tem do ponto de vista de compatibilidade de origem. Se libfoo2 for compatível com origem com libfoo3 , mas não com libfoo1 , e você tiver libfoo2 , o makefile resultante funcionará construindo um binário vinculado a libfoo2 ou um binário vinculado a libfoo3 , mas não um binário vinculado a libfoo1 (a compilação falharia devido à incompatibilidade no nível de origem).

Quando o executável é compilado e vinculado, o requisito da versão se torna mais preciso: o executável resultante precisa de uma biblioteca compatível com o binário (mesma ABI, não apenas a mesma API).

Os executáveis não codificam caminhos completos para as bibliotecas; codificam nomes de bibliotecas ( -l argumento para o vinculador) e, às vezes, um caminho de pesquisa da biblioteca de tempo de execução ( -rpath ) que vem além do caminho de pesquisa padrão do sistema de destino. Encontrar as bibliotecas em tempo de execução é o trabalho do vinculador dinâmico .

Eu recomendo jogar um pouco com ldd e strace . ldd mostra as bibliotecas requeridas por um executável e onde o sistema as encontraria. strace mostra todas as chamadas do sistema que acontecem quando um programa é carregado; os primeiros vêm do vinculador dinâmico que carrega as bibliotecas necessárias. Aqui estão algumas experiências cujos resultados você deve tentar entender.

ldd /bin/true
strace /bin/true
perl -pe 's/libc\.so/libc.zz/' </bin/true >broken
chmod +x broken
ldd ./broken
strace ./broken
ln -s /lib/libc.so.6 libc.zz.6
LD_LIBRARY_PATH=. strace ./broken

Resumindo as respostas para suas perguntas específicas:

  1. configure codifica problemas de compatibilidade de origem. A etapa make codifica problemas de compatibilidade binária. Os locais da biblioteca são determinados em tempo de execução.
  2. Se apenas o local da biblioteca foi alterado, o vinculador dinâmico normalmente o encontrará (se você tiver uma biblioteca instalada em um local fora do padrão, passe a variável de ambiente LD_LIBRARY_PATH ). Se você tem apenas uma versão diferente da biblioteca, então não é a mesma biblioteca; você precisa obter uma biblioteca com a versão ABI que seu programa é compilado, ou compilar seu programa com a versão ABI para a qual você tem a biblioteca instalada.
  3. configure determina a configuração de compilação do que você tem em seu sistema e os argumentos que você passa. make constrói o executável e outros bits. make install copia os bits no lugar; somente esse estágio pode exigir permissões elevadas (se você ainda não tiver permissão para gravar no diretório de destino, por exemplo, se estivesse instalando em seu diretório pessoal).
  4. configure sobrescreve o makefile, mas re-executar configure não inicia do zero porque mantém um cache.
por Gilles 02.07.2011 / 12:13
1

Eu acredito que quando você ./configure em um computador, ele deriva um makefile específico para aquele computador, então quando você transfere o programa compilado, a biblioteca não é onde o makefile (ou o executável) sabia que era, então ele jogue fora um erro. Como você pode ver, quando você configura, nem toda biblioteca verificada é necessária. Por isso, deve fazer um makefile diferente, dependendo do seu sistema. Outro exemplo disso é que quando você tem uma arquitetura diferente, ela requer bibliotecas diferentes e assim por diante.

E sim, você tem o pedido correto. 'make' é o comando safe, apenas trabalhando no diretório atual, o sudo é basicamente necessário para 'make install'. É ruim não ter privilégios de root ao instalar o software.

    
por Jared Engler 01.07.2011 / 03:49