Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pt.comp.programacao > #318 > unrolled thread

GNU screen, FreeBSD 14

Back to article view | Back to pt.comp.programacao

Contents

  GNU screen, FreeBSD 14 Patricia Ferreira <pferreira@example.com> - 2024-11-01 20:21 -0300
    Re: GNU screen, FreeBSD 14 Daniel Cerqueira <dan.list@lispclub.com> - 2024-11-02 13:38 +0000
      Re: GNU screen, FreeBSD 14 Patricia Ferreira <pferreira@example.com> - 2024-11-05 16:51 -0300
        Re: GNU screen, FreeBSD 14 Daniel Cerqueira <dan.list@lispclub.com> - 2024-11-05 20:31 +0000
          Re: GNU screen, FreeBSD 14 Patricia Ferreira <pferreira@example.com> - 2024-11-05 18:39 -0300
            Re: GNU screen, FreeBSD 14 Daniel Cerqueira <dan.list@lispclub.com> - 2024-11-05 21:58 +0000
              Re: GNU screen, FreeBSD 14 Patricia Ferreira <pferreira@example.com> - 2024-11-05 19:23 -0300
                Re: GNU screen, FreeBSD 14 Daniel Cerqueira <dan.list@lispclub.com> - 2024-11-06 04:52 +0000

#318 — GNU screen, FreeBSD 14

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í?

[toc] | [next] | [standalone]

#319

Patricia Ferreira <pferreira@example.com> 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.

Se não resultar, usa o `strace` para ver se há alguma biblioteca não
existente. Para usar o `strace` o programa tem de estar a correr, e
depois ligaste ao pid do programa (provavelmente o teu problema é por o
screen a correr).

[toc] | [prev] | [next] | [standalone]

#320

Daniel Cerqueira <dan.list@lispclub.com> writes:

> Patricia Ferreira <pferreira@example.com> 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.

[toc] | [prev] | [next] | [standalone]

#323

Patricia Ferreira <pferreira@example.com> writes:

> Daniel Cerqueira <dan.list@lispclub.com> writes:
>
>> Patricia Ferreira <pferreira@example.com> 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.

[toc] | [prev] | [next] | [standalone]

#325

Daniel Cerqueira <dan.list@lispclub.com> writes:

> Patricia Ferreira <pferreira@example.com> writes:
>
>> Daniel Cerqueira <dan.list@lispclub.com> writes:
>>
>>> Patricia Ferreira <pferreira@example.com> 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''.

[toc] | [prev] | [next] | [standalone]

#326

Patricia Ferreira <pferreira@example.com> writes:

> Daniel Cerqueira <dan.list@lispclub.com> writes:
>
>> Patricia Ferreira <pferreira@example.com> writes:
>>
>>> Daniel Cerqueira <dan.list@lispclub.com> writes:
>>>
>>>> Patricia Ferreira <pferreira@example.com> 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''.

Escolhe uma biblioteca para instalares manulmente. Depois corre
`ldconfig -p | grep o nome-dessa-biblioteca` (deves encontrar nenhuma ou
apenas em /usr/lib/). Depois instala a biblioteca. Corre `ldconfig -p |
grep o nome-dessa-biblioteca` e vais ver que ainda não é detetada pelo
sistema. Tens de correr o `ldconfig` para detetar a nova biblioteca.

Agora corres `ldconfig -p | grep o nome-dessa-biblioteca` e já detetas a
nova biblioteca em /usr/local/lib/ .

[toc] | [prev] | [next] | [standalone]

#328

Daniel Cerqueira <dan.list@lispclub.com> writes:

> Patricia Ferreira <pferreira@example.com> writes:
>
>> Daniel Cerqueira <dan.list@lispclub.com> writes:
>>
>>> Patricia Ferreira <pferreira@example.com> writes:
>>>
>>>> Daniel Cerqueira <dan.list@lispclub.com> writes:
>>>>
>>>>> Patricia Ferreira <pferreira@example.com> 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''.
>
> Escolhe uma biblioteca para instalares manulmente. Depois corre
> `ldconfig -p | grep o nome-dessa-biblioteca` (deves encontrar nenhuma ou
> apenas em /usr/lib/). Depois instala a biblioteca. Corre `ldconfig -p |
> grep o nome-dessa-biblioteca` e vais ver que ainda não é detetada pelo
> sistema. Tens de correr o `ldconfig` para detetar a nova biblioteca.
>
> Agora corres `ldconfig -p | grep o nome-dessa-biblioteca` e já detetas a
> nova biblioteca em /usr/local/lib/ .

Okay, mas note que o problema com o GNU screen não tinha conexão com uma
biblioteca ausente.  A propósito:

# ldconfig -p
ldconfig: illegal option -- p
usage: ldconfig [-32] [-BRimr] [-f hints_file][directory | file ...]

[toc] | [prev] | [next] | [standalone]

#330

Patricia Ferreira <pferreira@example.com> writes:

> Daniel Cerqueira <dan.list@lispclub.com> writes:
>
>> Patricia Ferreira <pferreira@example.com> writes:
>>
>>> Daniel Cerqueira <dan.list@lispclub.com> writes:
>>>
>>>> Patricia Ferreira <pferreira@example.com> writes:
>>>>
>>>>> Daniel Cerqueira <dan.list@lispclub.com> writes:
>>>>>
>>>>>> Patricia Ferreira <pferreira@example.com> 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''.
>>
>> Escolhe uma biblioteca para instalares manulmente. Depois corre
>> `ldconfig -p | grep o nome-dessa-biblioteca` (deves encontrar nenhuma ou
>> apenas em /usr/lib/). Depois instala a biblioteca. Corre `ldconfig -p |
>> grep o nome-dessa-biblioteca` e vais ver que ainda não é detetada pelo
>> sistema. Tens de correr o `ldconfig` para detetar a nova biblioteca.
>>
>> Agora corres `ldconfig -p | grep o nome-dessa-biblioteca` e já detetas a
>> nova biblioteca em /usr/local/lib/ .
>
> Okay, mas note que o problema com o GNU screen não tinha conexão com uma
> biblioteca ausente.  A propósito:

Mas pode ter conexâo com uma biblioteca desatualizada em cache.

> # ldconfig -p
> ldconfig: illegal option -- p
> usage: ldconfig [-32] [-BRimr] [-f hints_file][directory | file ...]

Nâo sei como funciona o teu ldconfig aí. Aqui tem a opção "-p" ou
"--print-cache", que faz "Imprimir a cache".

[toc] | [prev] | [standalone]

Back to top | Article view | pt.comp.programacao

csiph-web