1. Existe conflito de libs no Slackware? [RESOLVIDO]
homemsemnomeusa Debian
Post recolhido
Enviado em 23/02/2017 - 01:53h
Se eu for compilar versões mais novas de determinados pacotes no Debian stable e tiver que adicionar várias libs recentes no sistema, provavelmente irá dar alguma merd*, não?! Mas e no Slackware, como isso funciona? Vejo que a necessidade de se compilar pacotes no Slackware é maior, e nesse caso, como fica? Pode-se adicionar libs novas e "velhas" no sistema? A modularidade do Slackware permite isso? No caso dos Slackbuilds existe algum padrão para as versões dos pacotes e libs ou eles disponibilizam o que bem entenderem mesmo?
2. Re: Existe conflito de libs no Slackware? [RESOLVIDO]
Melhor resposta
removidousa Nenhuma
Post recolhido
Enviado em 23/02/2017 - 07:44h
homemsemnome escreveu:
Se eu for compilar versões mais novas de determinados pacotes no Debian stable e tiver que adicionar várias libs recentes no sistema, provavelmente irá dar alguma merd*, não?!
Não necessariamente, pois por default quando se compila um pacote, as libs, binários, man pages, etc vão para a pasta /usr/local, diferente dos pacotes do sistema que usam a pasta /usr.
Para causar um conflito, seria necessário passar o prefixo para /usr (./configure --prefix=/usr), porém mesmo assim pode ser que não quebre o pacote mais antigo, dependendo da complexidade do mesmo.
Mas, mesmo que as libs fiquem armazenadas em /usr/local, na hora de rodar um binário a preferência para carregar bibliotecas é em /usr/lib. Geralmente usa-se a variável de ambiente LD_LIBRARY_PATH para determinar outro local para carregar libs, como por exemplo: LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/binario
* Na hora da compilação, para utilizar as bibliotecas e includes da pasta /usr/local, basta especificar isso nas variáveis LDFLAGS e CFLAGS:
Dessa forma, o pacote será compilado com as bibliotecas instaladas em /usr/local e dependerá dessas para a sua execução.
Mas e no Slackware, como isso funciona? Vejo que a necessidade de se compilar pacotes no Slackware é maior, e nesse caso, como fica? Pode-se adicionar libs novas e "velhas" no sistema? A modularidade do Slackware permite isso? No caso dos Slackbuilds existe algum padrão para as versões dos pacotes e libs ou eles disponibilizam o que bem entenderem mesmo?
Valeu.
No SlackBuilds.org não é permitido adicionar pacotes que já possuem versões na árvore oficial. No caso de instalar um pacote mais recente por compilação manual, é o mesmo caso dito acima.
Porém, para evitar danos no sistema é recomendado substituir o pacote antigo do que manter duas versões.
-- Microsoft Windows é como ar condicionado
Pára de funcionar quando você abre uma janela.
Linux Counter: #596371
3. Re: Existe conflito de libs no Slackware? [RESOLVIDO]
homemsemnomeusa Debian
Post recolhido
Enviado em 23/02/2017 - 19:33h
ru4n escreveu:
Porr* Ruan, que boa notícia velho. Sempre ouvi dizer que era perigoso se adicionar pacotes recentes no Debian stable e por isso nunca o fiz. No máximo um backport. Mas vem cá, caso o pacote que eu esteja compilando exija libs externas, como eu faço para jogá-las em /usr/local/lib? É que eu ando seguindo a dica de um bródi daqui do VOL para compilar pacotes sem permissão root e aí eu costumo utilizar o --prefix=/opt/non-root para compilar o pacote. Só que quando for exigidas libs externas, como eu faço para adicionar essas libs mais recentes (baixadas fora dos repositórios oficiais, talvez) em /usr/local/lib? É só jogá-las lá e descompactá-las mesmo ou tem algo mais a se fazer? Fiquei contente em descobrir esse truque mano.
E só recapitulando aqui então para ver se eu entendi: primeiro eu direciono as libs mais novas para /usr/local/lib, depois eu ajusto o LD_LIBRARY_PATH, compilo o pacote com as variáveis LDFLAGS e CFLAGS e parto para o abraço?
Muito obrigado.
4. Re: Existe conflito de libs no Slackware? [RESOLVIDO]
removidousa Nenhuma
Post recolhido
Enviado em 24/02/2017 - 08:59h
homemsemnome escreveu:
Porr* Ruan, que boa notícia velho. Sempre ouvi dizer que era perigoso se adicionar pacotes recentes no Debian stable e por isso nunca o fiz. No máximo um backport. Mas vem cá, caso o pacote que eu esteja compilando exija libs externas, como eu faço para jogá-las em /usr/local/lib? É que eu ando seguindo a dica de um bródi daqui do VOL para compilar pacotes sem permissão root e aí eu costumo utilizar o --prefix=/opt/non-root para compilar o pacote. Só que quando for exigidas libs externas, como eu faço para adicionar essas libs mais recentes (baixadas fora dos repositórios oficiais, talvez) em /usr/local/lib? É só jogá-las lá e descompactá-las mesmo ou tem algo mais a se fazer? Fiquei contente em descobrir esse truque mano.
E só recapitulando aqui então para ver se eu entendi: primeiro eu direciono as libs mais novas para /usr/local/lib, depois eu ajusto o LD_LIBRARY_PATH, compilo o pacote com as variáveis LDFLAGS e CFLAGS e parto para o abraço?
Muito obrigado.
Tipo, se o pacote exige uma lib que esta instalada em /usr/lib, o pacote vai ser compilado em compatibilidade com essa lib. Se ele exige libs mais recentes, tu pode compilar essas bibliotecas mais recentes e mandá-las para outro local que quiser (via prefix e outras opções), por exemplo;
Essas são algumas opções padrões para o configure, geralmente são essas (para ver mais: ./configure --help). Fazendo isso, a pasta /home/usuario/opt vai se tornando uma nova raíz, com pastas como etc, usr, var, e outras.
Para compilar pacotes usando as bibliotecas dessa pasta, basta setar as variáveis LDFLAGS e CFLAGS antes do ./configure. Por exemplo, quero compilar um novo pacote que necessite da biblioteca que instalei agora pouco na pasta /home/usuario/opt, então faço:
Fazendo dessa forma, o pacote vai ser compilado em compatibilidade com a biblioteca instala em /home/usuario/opt e não mais em /usr. Entretanto, esse é um modo que dá muito trabalho, afinal será necessário compilar bibliotecas mais novas e talvez algumas dessas não será trivial, exigindo algum patch e/ou alguma lib do core mais recente. Mas é possível.
O LD_LIBRARY_PATH seria para o seu pacote procurar as libs necessárias em outro local ao invés do padrão do sistema, que é em /usr/lib (ou /usr/lib64). Nesse caso, teria que que setar essa variável antes de executar o binário que foi instalado em /home/usuario/opt. Por ex: