Path: csiph.com!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Patricia Ferreira Newsgroups: pt.comp.programacao Subject: Re: GNU screen, FreeBSD 14 Date: Tue, 05 Nov 2024 18:39:20 -0300 Organization: A noiseless patient Spider Lines: 73 Message-ID: <874j4lpdh3.fsf@example.com> References: <874j4qy1zg.fsf@example.com> <87ttcpah7u.fsf@lispclub.com> <87bjytsblt.fsf@example.com> <87ldxx4e3f.fsf@lispclub.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Tue, 05 Nov 2024 22:39:22 +0100 (CET) Injection-Info: dont-email.me; posting-host="b13872127e8275801f8ca0eb3286b883"; logging-data="1815688"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Wyw/PknwzLTXHXZyLnxC1FzkV2DuVqjY=" Cancel-Lock: sha1:Wqlbsv2sMMFtR1Oet/DpykduiAk= sha1:HdH9K4rcROtdjBcScVH1nEoox2I= Xref: csiph.com pt.comp.programacao:325 Daniel Cerqueira writes: > Patricia Ferreira writes: > >> Daniel Cerqueira writes: >> >>> Patricia Ferreira writes: >>> >>>> Nunca tinha visto isso antes. >>>> >>>> # screen >>>> ld-elf.so.1: /lib/libc.so.7: version FBSD_1.8 required by >>>> /usr/local/bin/screen not found >>>> >>>> # ldd $(which screen) >>>> /usr/local/bin/screen: >>>> libncursesw.so.9 => /lib/libncursesw.so.9 (0x2491b92b1000) >>>> libtinfow.so.9 => /lib/libtinfow.so.9 (0x2491b7dff000) >>>> libutil.so.9 => /lib/libutil.so.9 (0x2491b84c2000) >>>> libulog.so.0 => /lib/libulog.so.0 (0x2491b9f04000) >>>> libcrypt.so.5 => /lib/libcrypt.so.5 (0x2491ba31d000) >>>> libc.so.7 => /lib/libc.so.7 (0x2491ba6aa000) >>>> libmd.so.6 => /lib/libmd.so.6 (0x2491bb457000) >>>> [vdso] (0x2491b7ce3000) >>>> >>>> Qual será o problema aí? >>> >>> Corre o `ldconfig` e vê se resulta. >> >> Obrigado! O problema não é ausência de bibliotecas---note o que diz o >> ldd. O problema é que a libc.so.7 contra a qual o GNU screen foi >> compilado é diferente da libc.so.7 que o sistema possui. É uma pequena >> falha de sincronia entre os binários do FreeBSD e o sistema base. >> >> Podemos resolver a questão recompilando o screen diretamente do >> código-fonte, o que é fácil com o ports collection do FreeBSD. Assim a >> libc.so.7 do sistema mesmo seria usada. Mas nem consegui usar o ports >> porque o ports também reclamava do fato de que meu sistema era o >> FreeBSD-RELEASE 14.0 e o ports já assume que você tem o FreeBSD-RELEASE >> 14.1. Fiquei espantando com a pressa dos programadores. :) Mas como >> estou em início de vida com o FreeBSD, fiz o upgrade e observei que a >> string FBSD_1.8 já aparece no FreeBSD-RELEASE 14.1: >> >> %strings /lib/libc.so.7 | grep FBSD >> FBSD_1.0 >> FBSD_1.1 >> FBSD_1.2 >> FBSD_1.3 >> FBSD_1.4 >> FBSD_1.5 >> FBSD_1.6 >> FBSD_1.7 >> FBSD_1.8 >> FBSDprivate_1.0 >> >> Com isso o mesmo GNU screen que não rodava antes, agora roda. E também >> a partir daí já consigo usar o ports---compilei também o GNU screen sem >> problema por lá, mas já o desinstalei e fiquei com a versão do >> repositório binário mesmo. >> >> Obrigado pela atenção. > > Na minha distribuição, as bibliotecas ficam em cache, por isso às vezes > é preciso correr o ldconfig para as novas bibliotecas seram detetadas. > > Descobri isto recentemente. > > O ldconfig faz parte da glibc. Faz parte do FreeBSD também. No FreeBSD pelo menos, o ldconfig nada mais é que um gerenciador de uma lista de diretórios onde o dynamic linker procura por shared libraries. Não compreendo muito o que seria ``ficar em cache''.