* Newer hwcap failures
@ 2021-01-28 18:47 Adhemerval Zanella
2021-01-28 18:52 ` Adhemerval Zanella
2021-01-28 19:53 ` Florian Weimer
0 siblings, 2 replies; 19+ messages in thread
From: Adhemerval Zanella @ 2021-01-28 18:47 UTC (permalink / raw)
To: GNU C Library, Florian Weimer
Hi Florian,
I am seeing two tests failures on system with support 32-bit and 64-bit
ABIs (powerpc, sparc, x86). All of them are 64-bit kernel and userland
running 32-bit ABIs.
FAIL: elf/tst-glibc-hwcaps-prepend-cache
FAIL: elf/tst-ldconfig-ld_so_conf-update
$ cat elf/tst-ldconfig-ld_so_conf-update.out
error: tst-ldconfig-ld_so_conf-update.c:112: not true: dlopen (DSO, RTLD_NOW | RTLD_GLOBAL) != NULL
error: 1 test failures
running post-clean rsync
$ cat elf/tst-glibc-hwcaps-prepend-cache.out
error: xdlfcn.c:29: error: dlopen: libmarkermod1.so: cannot open shared object file: No such file or directory
error: 1 test failures
running post-clean rsync
Debugging the tst-ldconfig-ld_so_conf-update it seems that for some
reason ldconfig is not updating the search path. Modifying the testcase
to print the dlerror:
dlopen (libldconfig-ld-mod.so): libldconfig-ld-mod.so: cannot open shared object file: No such file or directory
I am trying to run strace on the container environment, but it seems
that it gets confused (it triggers a failure in the rename call).
Any idea?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-28 18:47 Newer hwcap failures Adhemerval Zanella
@ 2021-01-28 18:52 ` Adhemerval Zanella
2021-01-28 19:53 ` Florian Weimer
1 sibling, 0 replies; 19+ messages in thread
From: Adhemerval Zanella @ 2021-01-28 18:52 UTC (permalink / raw)
To: GNU C Library, Florian Weimer
On 28/01/2021 15:47, Adhemerval Zanella wrote:
> Hi Florian,
>
> I am seeing two tests failures on system with support 32-bit and 64-bit
> ABIs (powerpc, sparc, x86). All of them are 64-bit kernel and userland
> running 32-bit ABIs.
>
> FAIL: elf/tst-glibc-hwcaps-prepend-cache
> FAIL: elf/tst-ldconfig-ld_so_conf-update
>
> $ cat elf/tst-ldconfig-ld_so_conf-update.out
> error: tst-ldconfig-ld_so_conf-update.c:112: not true: dlopen (DSO, RTLD_NOW | RTLD_GLOBAL) != NULL
> error: 1 test failures
> running post-clean rsync
>
> $ cat elf/tst-glibc-hwcaps-prepend-cache.out
> error: xdlfcn.c:29: error: dlopen: libmarkermod1.so: cannot open shared object file: No such file or directory
>
> error: 1 test failures
> running post-clean rsync
>
>
> Debugging the tst-ldconfig-ld_so_conf-update it seems that for some
> reason ldconfig is not updating the search path. Modifying the testcase
> to print the dlerror:
>
> dlopen (libldconfig-ld-mod.so): libldconfig-ld-mod.so: cannot open shared object file: No such file or directory
>
> I am trying to run strace on the container environment, but it seems
> that it gets confused (it triggers a failure in the rename call).
>
> Any idea?
Also as a side note, I think it would be useful to add a note
about this new glibc-hwcap feature on NEWS.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-28 18:47 Newer hwcap failures Adhemerval Zanella
2021-01-28 18:52 ` Adhemerval Zanella
@ 2021-01-28 19:53 ` Florian Weimer
2021-01-28 20:01 ` Adhemerval Zanella
1 sibling, 1 reply; 19+ messages in thread
From: Florian Weimer @ 2021-01-28 19:53 UTC (permalink / raw)
To: Adhemerval Zanella; +Cc: GNU C Library
* Adhemerval Zanella:
> Debugging the tst-ldconfig-ld_so_conf-update it seems that for some
> reason ldconfig is not updating the search path. Modifying the testcase
> to print the dlerror:
>
> dlopen (libldconfig-ld-mod.so): libldconfig-ld-mod.so: cannot open shared object file: No such file or directory
>
> I am trying to run strace on the container environment, but it seems
> that it gets confused (it triggers a failure in the rename call).
>
> Any idea?
Do you use any special compiler flags? We have a report of ISA level
property notes showing up unexpectedly:
<https://sourceware.org/pipermail/libc-help/2021-January/005648.html>
I don't think this test has been adjusted to this new feature, it will
only work if the objects have no markup.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-28 19:53 ` Florian Weimer
@ 2021-01-28 20:01 ` Adhemerval Zanella
2021-01-28 20:21 ` Adhemerval Zanella
0 siblings, 1 reply; 19+ messages in thread
From: Adhemerval Zanella @ 2021-01-28 20:01 UTC (permalink / raw)
To: Florian Weimer; +Cc: GNU C Library
On 28/01/2021 16:53, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>> Debugging the tst-ldconfig-ld_so_conf-update it seems that for some
>> reason ldconfig is not updating the search path. Modifying the testcase
>> to print the dlerror:
>>
>> dlopen (libldconfig-ld-mod.so): libldconfig-ld-mod.so: cannot open shared object file: No such file or directory
>>
>> I am trying to run strace on the container environment, but it seems
>> that it gets confused (it triggers a failure in the rename call).
>>
>> Any idea?
>
> Do you use any special compiler flags? We have a report of ISA level
> property notes showing up unexpectedly:
>
> <https://sourceware.org/pipermail/libc-help/2021-January/005648.html>
>
> I don't think this test has been adjusted to this new feature, it will
> only work if the objects have no markup.
This is failing on powerpc32 as well with the same error, so I am not sure
this is really related to the ISA level property notes.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-28 20:01 ` Adhemerval Zanella
@ 2021-01-28 20:21 ` Adhemerval Zanella
2021-01-28 20:30 ` Adhemerval Zanella
0 siblings, 1 reply; 19+ messages in thread
From: Adhemerval Zanella @ 2021-01-28 20:21 UTC (permalink / raw)
To: Florian Weimer; +Cc: GNU C Library
On 28/01/2021 17:01, Adhemerval Zanella wrote:
>
>
> On 28/01/2021 16:53, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>>> Debugging the tst-ldconfig-ld_so_conf-update it seems that for some
>>> reason ldconfig is not updating the search path. Modifying the testcase
>>> to print the dlerror:
>>>
>>> dlopen (libldconfig-ld-mod.so): libldconfig-ld-mod.so: cannot open shared object file: No such file or directory
>>>
>>> I am trying to run strace on the container environment, but it seems
>>> that it gets confused (it triggers a failure in the rename call).
>>>
>>> Any idea?
>>
>> Do you use any special compiler flags? We have a report of ISA level
>> property notes showing up unexpectedly:
>>
>> <https://sourceware.org/pipermail/libc-help/2021-January/005648.html>
>>
>> I don't think this test has been adjusted to this new feature, it will
>> only work if the objects have no markup.
>
> This is failing on powerpc32 as well with the same error, so I am not sure
> this is really related to the ISA level property notes.
The libldconfig-ld-mod.so is indeed listed on the cache, as indicated by
a 'ldconfig -p' after the final 'ldconfig' onelf/tst-ldconfig-ld_so_conf-update.c:
37 libs found in cache `/etc/ld.so.cache'
libutil.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libutil.so.1
libutil.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libutil.so
libthread_db.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libthread_db.so.1
libthread_db.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libthread_db.so
librt.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/librt.so.1
librt.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/librt.so
libresolv.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libresolv.so.2
libresolv.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libresolv.so
libpthread.so.0 (libc6, OS ABI: Linux 3.2.0) => /lib/libpthread.so.0
libpthread.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libpthread.so
libpcprofile.so (libc6, OS ABI: Linux 3.2.0) => /lib/libpcprofile.so
libnss_hesiod.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_hesiod.so.2
libnss_hesiod.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_hesiod.so
libnss_files.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_files.so.2
libnss_files.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_files.so
libnss_dns.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_dns.so.2
libnss_dns.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_dns.so
libnss_db.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_db.so.2
libnss_db.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_db.so
libnss_compat.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_compat.so.2
libnss_compat.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_compat.so
libnsl.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libnsl.so.1
libmemusage.so (libc6, OS ABI: Linux 3.2.0) => /lib/libmemusage.so
libm.so.6 (libc6, OS ABI: Linux 3.2.0) => /lib/libm.so.6
libm.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libm.so
libldconfig-ld-mod.so (libc6, OS ABI: Linux 3.2.0) => /tmp/tst-ldconfig/libldconfig-ld-mod.so
libdl.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libdl.so.2
libdl.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libdl.so
libcrypt.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libcrypt.so.1
libcrypt.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libcrypt.so
libc.so.6 (libc6, OS ABI: Linux 3.2.0) => /lib/libc.so.6
libanl.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libanl.so.1
libanl.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libanl.so
libSegFault.so (libc6, OS ABI: Linux 3.2.0) => /lib/libSegFault.so
libBrokenLocale.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libBrokenLocale.so.1
libBrokenLocale.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libBrokenLocale.so
ld-linux.so.2 (ELF) => /lib/ld-linux.so.2
However the dlopen is not considering it on search path, as indicated by
LD_DEBUG=all just before the dlopen failure:
1: file=libldconfig-ld-mod.so [0]; dynamically loaded by /xxx/i686-linux-gnu/elf/tst-ldconfig-ld_so_conf-update [0]
1: find library=libldconfig-ld-mod.so [0]; searching
1: search cache=/etc/ld.so.cache
1: search path=/lib:/usr/lib (system search path)
1: trying file=/lib/libldconfig-ld-mod.so
1: trying file=/usr/lib/libldconfig-ld-mod.so
I am not sure why yet.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-28 20:21 ` Adhemerval Zanella
@ 2021-01-28 20:30 ` Adhemerval Zanella
2021-01-28 21:23 ` Adhemerval Zanella
0 siblings, 1 reply; 19+ messages in thread
From: Adhemerval Zanella @ 2021-01-28 20:30 UTC (permalink / raw)
To: Florian Weimer; +Cc: GNU C Library
On 28/01/2021 17:21, Adhemerval Zanella wrote:
>
>
> On 28/01/2021 17:01, Adhemerval Zanella wrote:
>>
>>
>> On 28/01/2021 16:53, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> Debugging the tst-ldconfig-ld_so_conf-update it seems that for some
>>>> reason ldconfig is not updating the search path. Modifying the testcase
>>>> to print the dlerror:
>>>>
>>>> dlopen (libldconfig-ld-mod.so): libldconfig-ld-mod.so: cannot open shared object file: No such file or directory
>>>>
>>>> I am trying to run strace on the container environment, but it seems
>>>> that it gets confused (it triggers a failure in the rename call).
>>>>
>>>> Any idea?
>>>
>>> Do you use any special compiler flags? We have a report of ISA level
>>> property notes showing up unexpectedly:
>>>
>>> <https://sourceware.org/pipermail/libc-help/2021-January/005648.html>
>>>
>>> I don't think this test has been adjusted to this new feature, it will
>>> only work if the objects have no markup.
>>
>> This is failing on powerpc32 as well with the same error, so I am not sure
>> this is really related to the ISA level property notes.
>
> The libldconfig-ld-mod.so is indeed listed on the cache, as indicated by
> a 'ldconfig -p' after the final 'ldconfig' onelf/tst-ldconfig-ld_so_conf-update.c:
>
> 37 libs found in cache `/etc/ld.so.cache'
> libutil.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libutil.so.1
> libutil.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libutil.so
> libthread_db.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libthread_db.so.1
> libthread_db.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libthread_db.so
> librt.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/librt.so.1
> librt.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/librt.so
> libresolv.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libresolv.so.2
> libresolv.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libresolv.so
> libpthread.so.0 (libc6, OS ABI: Linux 3.2.0) => /lib/libpthread.so.0
> libpthread.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libpthread.so
> libpcprofile.so (libc6, OS ABI: Linux 3.2.0) => /lib/libpcprofile.so
> libnss_hesiod.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_hesiod.so.2
> libnss_hesiod.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_hesiod.so
> libnss_files.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_files.so.2
> libnss_files.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_files.so
> libnss_dns.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_dns.so.2
> libnss_dns.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_dns.so
> libnss_db.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_db.so.2
> libnss_db.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_db.so
> libnss_compat.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_compat.so.2
> libnss_compat.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_compat.so
> libnsl.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libnsl.so.1
> libmemusage.so (libc6, OS ABI: Linux 3.2.0) => /lib/libmemusage.so
> libm.so.6 (libc6, OS ABI: Linux 3.2.0) => /lib/libm.so.6
> libm.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libm.so
> libldconfig-ld-mod.so (libc6, OS ABI: Linux 3.2.0) => /tmp/tst-ldconfig/libldconfig-ld-mod.so
> libdl.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libdl.so.2
> libdl.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libdl.so
> libcrypt.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libcrypt.so.1
> libcrypt.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libcrypt.so
> libc.so.6 (libc6, OS ABI: Linux 3.2.0) => /lib/libc.so.6
> libanl.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libanl.so.1
> libanl.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libanl.so
> libSegFault.so (libc6, OS ABI: Linux 3.2.0) => /lib/libSegFault.so
> libBrokenLocale.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libBrokenLocale.so.1
> libBrokenLocale.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libBrokenLocale.so
> ld-linux.so.2 (ELF) => /lib/ld-linux.so.2
>
> However the dlopen is not considering it on search path, as indicated by
> LD_DEBUG=all just before the dlopen failure:
>
> 1: file=libldconfig-ld-mod.so [0]; dynamically loaded by /xxx/i686-linux-gnu/elf/tst-ldconfig-ld_so_conf-update [0]
> 1: find library=libldconfig-ld-mod.so [0]; searching
> 1: search cache=/etc/ld.so.cache
> 1: search path=/lib:/usr/lib (system search path)
> 1: trying file=/lib/libldconfig-ld-mod.so
> 1: trying file=/usr/lib/libldconfig-ld-mod.so
>
> I am not sure why yet.
From my testings, I am seeing this issue on hppa, powerpc32 hardfloat, i686, and armhf.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-28 20:30 ` Adhemerval Zanella
@ 2021-01-28 21:23 ` Adhemerval Zanella
2021-01-28 22:03 ` DJ Delorie
2021-01-29 9:20 ` Florian Weimer
0 siblings, 2 replies; 19+ messages in thread
From: Adhemerval Zanella @ 2021-01-28 21:23 UTC (permalink / raw)
To: Florian Weimer; +Cc: GNU C Library
On 28/01/2021 17:30, Adhemerval Zanella wrote:
>
>
> On 28/01/2021 17:21, Adhemerval Zanella wrote:
>>
>>
>> On 28/01/2021 17:01, Adhemerval Zanella wrote:
>>>
>>>
>>> On 28/01/2021 16:53, Florian Weimer wrote:
>>>> * Adhemerval Zanella:
>>>>
>>>>> Debugging the tst-ldconfig-ld_so_conf-update it seems that for some
>>>>> reason ldconfig is not updating the search path. Modifying the testcase
>>>>> to print the dlerror:
>>>>>
>>>>> dlopen (libldconfig-ld-mod.so): libldconfig-ld-mod.so: cannot open shared object file: No such file or directory
>>>>>
>>>>> I am trying to run strace on the container environment, but it seems
>>>>> that it gets confused (it triggers a failure in the rename call).
>>>>>
>>>>> Any idea?
>>>>
>>>> Do you use any special compiler flags? We have a report of ISA level
>>>> property notes showing up unexpectedly:
>>>>
>>>> <https://sourceware.org/pipermail/libc-help/2021-January/005648.html>
>>>>
>>>> I don't think this test has been adjusted to this new feature, it will
>>>> only work if the objects have no markup.
>>>
>>> This is failing on powerpc32 as well with the same error, so I am not sure
>>> this is really related to the ISA level property notes.
>>
>> The libldconfig-ld-mod.so is indeed listed on the cache, as indicated by
>> a 'ldconfig -p' after the final 'ldconfig' onelf/tst-ldconfig-ld_so_conf-update.c:
>>
>> 37 libs found in cache `/etc/ld.so.cache'
>> libutil.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libutil.so.1
>> libutil.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libutil.so
>> libthread_db.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libthread_db.so.1
>> libthread_db.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libthread_db.so
>> librt.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/librt.so.1
>> librt.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/librt.so
>> libresolv.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libresolv.so.2
>> libresolv.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libresolv.so
>> libpthread.so.0 (libc6, OS ABI: Linux 3.2.0) => /lib/libpthread.so.0
>> libpthread.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libpthread.so
>> libpcprofile.so (libc6, OS ABI: Linux 3.2.0) => /lib/libpcprofile.so
>> libnss_hesiod.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_hesiod.so.2
>> libnss_hesiod.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_hesiod.so
>> libnss_files.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_files.so.2
>> libnss_files.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_files.so
>> libnss_dns.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_dns.so.2
>> libnss_dns.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_dns.so
>> libnss_db.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_db.so.2
>> libnss_db.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_db.so
>> libnss_compat.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libnss_compat.so.2
>> libnss_compat.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libnss_compat.so
>> libnsl.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libnsl.so.1
>> libmemusage.so (libc6, OS ABI: Linux 3.2.0) => /lib/libmemusage.so
>> libm.so.6 (libc6, OS ABI: Linux 3.2.0) => /lib/libm.so.6
>> libm.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libm.so
>> libldconfig-ld-mod.so (libc6, OS ABI: Linux 3.2.0) => /tmp/tst-ldconfig/libldconfig-ld-mod.so
>> libdl.so.2 (libc6, OS ABI: Linux 3.2.0) => /lib/libdl.so.2
>> libdl.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libdl.so
>> libcrypt.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libcrypt.so.1
>> libcrypt.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libcrypt.so
>> libc.so.6 (libc6, OS ABI: Linux 3.2.0) => /lib/libc.so.6
>> libanl.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libanl.so.1
>> libanl.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libanl.so
>> libSegFault.so (libc6, OS ABI: Linux 3.2.0) => /lib/libSegFault.so
>> libBrokenLocale.so.1 (libc6, OS ABI: Linux 3.2.0) => /lib/libBrokenLocale.so.1
>> libBrokenLocale.so (libc6, OS ABI: Linux 3.2.0) => /usr/lib/libBrokenLocale.so
>> ld-linux.so.2 (ELF) => /lib/ld-linux.so.2
>>
>> However the dlopen is not considering it on search path, as indicated by
>> LD_DEBUG=all just before the dlopen failure:
>>
>> 1: file=libldconfig-ld-mod.so [0]; dynamically loaded by /xxx/i686-linux-gnu/elf/tst-ldconfig-ld_so_conf-update [0]
>> 1: find library=libldconfig-ld-mod.so [0]; searching
>> 1: search cache=/etc/ld.so.cache
>> 1: search path=/lib:/usr/lib (system search path)
>> 1: trying file=/lib/libldconfig-ld-mod.so
>> 1: trying file=/usr/lib/libldconfig-ld-mod.so
>>
>> I am not sure why yet.
>
> From my testings, I am seeing this issue on hppa, powerpc32 hardfloat, i686, and armhf.
The issue is test-container is copying the ld.so.cache from system into
testroot and thus _dl_sysdep_read_whole_file does not fail.
For 32-bit builds, there is not ld.so.cache then _dl_sysdep_read_whole_file
fails and further ldconfig does not change the process map (since
_dl_load_cache_lookup won't reload the cache after an initial failure).
That's explain why I am seeing this only on system with default 64-bit
userland. I don't know exactly why I haven't see this before, neither
if it were some testing regression added recently.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-28 21:23 ` Adhemerval Zanella
@ 2021-01-28 22:03 ` DJ Delorie
2021-01-29 5:56 ` Florian Weimer
2021-01-29 9:20 ` Florian Weimer
1 sibling, 1 reply; 19+ messages in thread
From: DJ Delorie @ 2021-01-28 22:03 UTC (permalink / raw)
To: Adhemerval Zanella; +Cc: fweimer, libc-alpha
Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> writes:
> The issue is test-container is copying the ld.so.cache from system into
> testroot
It's not supposed to do that...
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-28 22:03 ` DJ Delorie
@ 2021-01-29 5:56 ` Florian Weimer
2021-01-29 6:07 ` DJ Delorie
2021-01-29 6:09 ` DJ Delorie
0 siblings, 2 replies; 19+ messages in thread
From: Florian Weimer @ 2021-01-29 5:56 UTC (permalink / raw)
To: DJ Delorie; +Cc: Adhemerval Zanella, libc-alpha
* DJ Delorie:
> Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> writes:
>> The issue is test-container is copying the ld.so.cache from system into
>> testroot
>
> It's not supposed to do that...
It's probably a left-over from an earlier non-destructive test in the
scenarios that are working.
Make version differences resulting in execution order variation could be
the reason why I haven't seen this myself.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-29 5:56 ` Florian Weimer
@ 2021-01-29 6:07 ` DJ Delorie
2021-01-29 6:09 ` DJ Delorie
1 sibling, 0 replies; 19+ messages in thread
From: DJ Delorie @ 2021-01-29 6:07 UTC (permalink / raw)
To: Florian Weimer; +Cc: adhemerval.zanella, libc-alpha
Florian Weimer <fweimer@redhat.com> writes:
> It's probably a left-over from an earlier non-destructive test in the
> scenarios that are working.
If so, this is what the postclean flag is for ;-)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-29 5:56 ` Florian Weimer
2021-01-29 6:07 ` DJ Delorie
@ 2021-01-29 6:09 ` DJ Delorie
1 sibling, 0 replies; 19+ messages in thread
From: DJ Delorie @ 2021-01-29 6:09 UTC (permalink / raw)
To: Florian Weimer; +Cc: adhemerval.zanella, libc-alpha
Florian Weimer <fweimer@redhat.com> writes:
> It's probably a left-over from an earlier non-destructive test in the
> scenarios that are working.
> If so, this is what the postclean flag is for ;-)
To be clearer, I meant, any test that leaves behind an ld.so.cache (or
anything that may affect future tests) should postclean (just in case)
but a test that is sensitive to ld.so.cache should also do a preclean.
This scenario is why I put those features in there.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-28 21:23 ` Adhemerval Zanella
2021-01-28 22:03 ` DJ Delorie
@ 2021-01-29 9:20 ` Florian Weimer
2021-01-29 10:43 ` Szabolcs Nagy
1 sibling, 1 reply; 19+ messages in thread
From: Florian Weimer @ 2021-01-29 9:20 UTC (permalink / raw)
To: Adhemerval Zanella; +Cc: GNU C Library
* Adhemerval Zanella:
> The issue is test-container is copying the ld.so.cache from system into
> testroot and thus _dl_sysdep_read_whole_file does not fail.
>
> For 32-bit builds, there is not ld.so.cache then _dl_sysdep_read_whole_file
> fails and further ldconfig does not change the process map (since
> _dl_load_cache_lookup won't reload the cache after an initial failure).
>
> That's explain why I am seeing this only on system with default 64-bit
> userland. I don't know exactly why I haven't see this before, neither
> if it were some testing regression added recently.
I can't reproduce this (with an x86-64 host and a multilib toolchain).
Does it require an i386 chroot to reproduce?
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-29 9:20 ` Florian Weimer
@ 2021-01-29 10:43 ` Szabolcs Nagy
2021-01-29 10:48 ` Florian Weimer
0 siblings, 1 reply; 19+ messages in thread
From: Szabolcs Nagy @ 2021-01-29 10:43 UTC (permalink / raw)
To: Florian Weimer; +Cc: Adhemerval Zanella, GNU C Library
The 01/29/2021 10:20, Florian Weimer via Libc-alpha wrote:
> * Adhemerval Zanella:
>
> > The issue is test-container is copying the ld.so.cache from system into
> > testroot and thus _dl_sysdep_read_whole_file does not fail.
> >
> > For 32-bit builds, there is not ld.so.cache then _dl_sysdep_read_whole_file
> > fails and further ldconfig does not change the process map (since
> > _dl_load_cache_lookup won't reload the cache after an initial failure).
> >
> > That's explain why I am seeing this only on system with default 64-bit
> > userland. I don't know exactly why I haven't see this before, neither
> > if it were some testing regression added recently.
>
> I can't reproduce this (with an x86-64 host and a multilib toolchain).
> Does it require an i386 chroot to reproduce?
i see those tests fail with a config.make that has
cross-compiling = maybe
then /etc/ld.so.cache is missing from the install
directory (since ldconfig is not run)
i normally use a i686-linux-gnu toolchain on an
x86_64 machine to test i686, not a chroot/container.
in an i686 container with native gcc the tests pass.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-29 10:43 ` Szabolcs Nagy
@ 2021-01-29 10:48 ` Florian Weimer
2021-01-29 10:51 ` Szabolcs Nagy
0 siblings, 1 reply; 19+ messages in thread
From: Florian Weimer @ 2021-01-29 10:48 UTC (permalink / raw)
To: Szabolcs Nagy; +Cc: Adhemerval Zanella, GNU C Library
* Szabolcs Nagy:
> The 01/29/2021 10:20, Florian Weimer via Libc-alpha wrote:
>> * Adhemerval Zanella:
>>
>> > The issue is test-container is copying the ld.so.cache from system into
>> > testroot and thus _dl_sysdep_read_whole_file does not fail.
>> >
>> > For 32-bit builds, there is not ld.so.cache then _dl_sysdep_read_whole_file
>> > fails and further ldconfig does not change the process map (since
>> > _dl_load_cache_lookup won't reload the cache after an initial failure).
>> >
>> > That's explain why I am seeing this only on system with default 64-bit
>> > userland. I don't know exactly why I haven't see this before, neither
>> > if it were some testing regression added recently.
>>
>> I can't reproduce this (with an x86-64 host and a multilib toolchain).
>> Does it require an i386 chroot to reproduce?
>
> i see those tests fail with a config.make that has
>
> cross-compiling = maybe
>
> then /etc/ld.so.cache is missing from the install
> directory (since ldconfig is not run)
>
> i normally use a i686-linux-gnu toolchain on an
> x86_64 machine to test i686, not a chroot/container.
> in an i686 container with native gcc the tests pass.
Hmm, how do you get that maybe? Do you rebuild ./configure using
autoconf 2.70 or later?
I see this in the configure file we ship:
# There might be people who depend on the old broken behavior: `$host'
# used to hold the argument of --host etc.
# FIXME: To remove some day.
build=$build_alias
host=$host_alias
target=$target_alias
# FIXME: To remove some day.
if test "x$host_alias" != x; then
if test "x$build_alias" = x; then
cross_compiling=maybe
elif test "x$build_alias" != "x$host_alias"; then
cross_compiling=yes
fi
fi
I configure glibc with --build=i686-linux-gnu, and that gives me
“cross-compiling = no” in config.make.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-29 10:48 ` Florian Weimer
@ 2021-01-29 10:51 ` Szabolcs Nagy
2021-01-29 11:53 ` Adhemerval Zanella
2021-01-29 12:31 ` Florian Weimer
0 siblings, 2 replies; 19+ messages in thread
From: Szabolcs Nagy @ 2021-01-29 10:51 UTC (permalink / raw)
To: Florian Weimer; +Cc: Adhemerval Zanella, GNU C Library
The 01/29/2021 11:48, Florian Weimer wrote:
> * Szabolcs Nagy:
>
> > The 01/29/2021 10:20, Florian Weimer via Libc-alpha wrote:
> >> * Adhemerval Zanella:
> >>
> >> > The issue is test-container is copying the ld.so.cache from system into
> >> > testroot and thus _dl_sysdep_read_whole_file does not fail.
> >> >
> >> > For 32-bit builds, there is not ld.so.cache then _dl_sysdep_read_whole_file
> >> > fails and further ldconfig does not change the process map (since
> >> > _dl_load_cache_lookup won't reload the cache after an initial failure).
> >> >
> >> > That's explain why I am seeing this only on system with default 64-bit
> >> > userland. I don't know exactly why I haven't see this before, neither
> >> > if it were some testing regression added recently.
> >>
> >> I can't reproduce this (with an x86-64 host and a multilib toolchain).
> >> Does it require an i386 chroot to reproduce?
> >
> > i see those tests fail with a config.make that has
> >
> > cross-compiling = maybe
> >
> > then /etc/ld.so.cache is missing from the install
> > directory (since ldconfig is not run)
> >
> > i normally use a i686-linux-gnu toolchain on an
> > x86_64 machine to test i686, not a chroot/container.
> > in an i686 container with native gcc the tests pass.
>
> Hmm, how do you get that maybe? Do you rebuild ./configure using
> autoconf 2.70 or later?
>
> I see this in the configure file we ship:
>
> # There might be people who depend on the old broken behavior: `$host'
> # used to hold the argument of --host etc.
> # FIXME: To remove some day.
> build=$build_alias
> host=$host_alias
> target=$target_alias
>
> # FIXME: To remove some day.
> if test "x$host_alias" != x; then
> if test "x$build_alias" = x; then
> cross_compiling=maybe
> elif test "x$build_alias" != "x$host_alias"; then
> cross_compiling=yes
> fi
> fi
>
> I configure glibc with --build=i686-linux-gnu, and that gives me
> “cross-compiling = no” in config.make.
hm ok i use --host=i686-linux-gnu but not build
may be i should add --build too.
(but in case of real cross compiling when i
run the tests with cross-wrapper+ssh then i
cannot change the --build and the tests will
fail)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-29 10:51 ` Szabolcs Nagy
@ 2021-01-29 11:53 ` Adhemerval Zanella
2021-01-29 12:46 ` H.J. Lu
2021-01-29 12:31 ` Florian Weimer
1 sibling, 1 reply; 19+ messages in thread
From: Adhemerval Zanella @ 2021-01-29 11:53 UTC (permalink / raw)
To: Szabolcs Nagy, Florian Weimer; +Cc: GNU C Library
On 29/01/2021 07:51, Szabolcs Nagy wrote:
> The 01/29/2021 11:48, Florian Weimer wrote:
>> * Szabolcs Nagy:
>>
>>> The 01/29/2021 10:20, Florian Weimer via Libc-alpha wrote:
>>>> * Adhemerval Zanella:
>>>>
>>>>> The issue is test-container is copying the ld.so.cache from system into
>>>>> testroot and thus _dl_sysdep_read_whole_file does not fail.
>>>>>
>>>>> For 32-bit builds, there is not ld.so.cache then _dl_sysdep_read_whole_file
>>>>> fails and further ldconfig does not change the process map (since
>>>>> _dl_load_cache_lookup won't reload the cache after an initial failure).
>>>>>
>>>>> That's explain why I am seeing this only on system with default 64-bit
>>>>> userland. I don't know exactly why I haven't see this before, neither
>>>>> if it were some testing regression added recently.
>>>>
>>>> I can't reproduce this (with an x86-64 host and a multilib toolchain).
>>>> Does it require an i386 chroot to reproduce?
>>>
>>> i see those tests fail with a config.make that has
>>>
>>> cross-compiling = maybe
>>>
>>> then /etc/ld.so.cache is missing from the install
>>> directory (since ldconfig is not run)
>>>
>>> i normally use a i686-linux-gnu toolchain on an
>>> x86_64 machine to test i686, not a chroot/container.
>>> in an i686 container with native gcc the tests pass.
>>
>> Hmm, how do you get that maybe? Do you rebuild ./configure using
>> autoconf 2.70 or later?
>>
>> I see this in the configure file we ship:
>>
>> # There might be people who depend on the old broken behavior: `$host'
>> # used to hold the argument of --host etc.
>> # FIXME: To remove some day.
>> build=$build_alias
>> host=$host_alias
>> target=$target_alias
>>
>> # FIXME: To remove some day.
>> if test "x$host_alias" != x; then
>> if test "x$build_alias" = x; then
>> cross_compiling=maybe
>> elif test "x$build_alias" != "x$host_alias"; then
>> cross_compiling=yes
>> fi
>> fi
>>
>> I configure glibc with --build=i686-linux-gnu, and that gives me
>> “cross-compiling = no” in config.make.
>
> hm ok i use --host=i686-linux-gnu but not build
> may be i should add --build too.
>
> (but in case of real cross compiling when i
> run the tests with cross-wrapper+ssh then i
> cannot change the --build and the tests will
> fail)
>
In my environment I use '--build=x86_64-linux-gnu --host=i686-linux-gnu' and
CFLAGS="x86_64-glibc-linux-gnu-gcc -m32" with a multiarch gcc built with
build-many-glibcs.py:
$ x86_64-glibc-linux-gnu-gcc -v
[...]
Configure with: [...] --with-multilib-list=m64,m32,mx32 [...]
This results in:
$ grep cross-compiling config.make
cross-compiling = yes
In most cases it does not interfere because cache won't be used. But I
still think we should fix to the test that actually check ldconfig
and ld.so.cache.
My idea to handle it is to add a new 'ldconfig' rule to *.script to
trigger a new ld.so.cache creation for container tests.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-29 10:51 ` Szabolcs Nagy
2021-01-29 11:53 ` Adhemerval Zanella
@ 2021-01-29 12:31 ` Florian Weimer
2021-01-29 13:06 ` Adhemerval Zanella
1 sibling, 1 reply; 19+ messages in thread
From: Florian Weimer @ 2021-01-29 12:31 UTC (permalink / raw)
To: Szabolcs Nagy via Libc-alpha
* Szabolcs Nagy via Libc-alpha:
> hm ok i use --host=i686-linux-gnu but not build
> may be i should add --build too.
I can reproduce the issue with
../git/configure --prefix=/usr CC="gcc -m32" CXX="g++ -m32" \
--host=i686-linux-gnu
on a multilib x86-64 system. This means that I now have something to
investigate.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-29 11:53 ` Adhemerval Zanella
@ 2021-01-29 12:46 ` H.J. Lu
0 siblings, 0 replies; 19+ messages in thread
From: H.J. Lu @ 2021-01-29 12:46 UTC (permalink / raw)
To: Adhemerval Zanella; +Cc: Szabolcs Nagy, Florian Weimer, GNU C Library
On Fri, Jan 29, 2021 at 4:30 AM Adhemerval Zanella via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
>
>
> On 29/01/2021 07:51, Szabolcs Nagy wrote:
> > The 01/29/2021 11:48, Florian Weimer wrote:
> >> * Szabolcs Nagy:
> >>
> >>> The 01/29/2021 10:20, Florian Weimer via Libc-alpha wrote:
> >>>> * Adhemerval Zanella:
> >>>>
> >>>>> The issue is test-container is copying the ld.so.cache from system into
> >>>>> testroot and thus _dl_sysdep_read_whole_file does not fail.
> >>>>>
> >>>>> For 32-bit builds, there is not ld.so.cache then _dl_sysdep_read_whole_file
> >>>>> fails and further ldconfig does not change the process map (since
> >>>>> _dl_load_cache_lookup won't reload the cache after an initial failure).
> >>>>>
> >>>>> That's explain why I am seeing this only on system with default 64-bit
> >>>>> userland. I don't know exactly why I haven't see this before, neither
> >>>>> if it were some testing regression added recently.
> >>>>
> >>>> I can't reproduce this (with an x86-64 host and a multilib toolchain).
> >>>> Does it require an i386 chroot to reproduce?
> >>>
> >>> i see those tests fail with a config.make that has
> >>>
> >>> cross-compiling = maybe
> >>>
> >>> then /etc/ld.so.cache is missing from the install
> >>> directory (since ldconfig is not run)
> >>>
> >>> i normally use a i686-linux-gnu toolchain on an
> >>> x86_64 machine to test i686, not a chroot/container.
> >>> in an i686 container with native gcc the tests pass.
> >>
> >> Hmm, how do you get that maybe? Do you rebuild ./configure using
> >> autoconf 2.70 or later?
> >>
> >> I see this in the configure file we ship:
> >>
> >> # There might be people who depend on the old broken behavior: `$host'
> >> # used to hold the argument of --host etc.
> >> # FIXME: To remove some day.
> >> build=$build_alias
> >> host=$host_alias
> >> target=$target_alias
> >>
> >> # FIXME: To remove some day.
> >> if test "x$host_alias" != x; then
> >> if test "x$build_alias" = x; then
> >> cross_compiling=maybe
> >> elif test "x$build_alias" != "x$host_alias"; then
> >> cross_compiling=yes
> >> fi
> >> fi
> >>
> >> I configure glibc with --build=i686-linux-gnu, and that gives me
> >> “cross-compiling = no” in config.make.
> >
> > hm ok i use --host=i686-linux-gnu but not build
> > may be i should add --build too.
> >
> > (but in case of real cross compiling when i
> > run the tests with cross-wrapper+ssh then i
> > cannot change the --build and the tests will
> > fail)
> >
>
> In my environment I use '--build=x86_64-linux-gnu --host=i686-linux-gnu' and
> CFLAGS="x86_64-glibc-linux-gnu-gcc -m32" with a multiarch gcc built with
> build-many-glibcs.py:
I use
BUILD_CC="gcc" CC="gcc -m32" CXX="g++ -m32" CFLAGS="-O2 -g
-march=i686" /export/gnu/import/git/sources/glibc/configure
--prefix=/usr --without-selinux --target=i686-linux --build=i686-linux
--host=i686-linux --enable-hardcoded-path-in-tests
to test i686 on x86-64.
> $ x86_64-glibc-linux-gnu-gcc -v
> [...]
> Configure with: [...] --with-multilib-list=m64,m32,mx32 [...]
>
> This results in:
>
> $ grep cross-compiling config.make
> cross-compiling = yes
>
> In most cases it does not interfere because cache won't be used. But I
> still think we should fix to the test that actually check ldconfig
> and ld.so.cache.
>
> My idea to handle it is to add a new 'ldconfig' rule to *.script to
> trigger a new ld.so.cache creation for container tests.
--
H.J.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Newer hwcap failures
2021-01-29 12:31 ` Florian Weimer
@ 2021-01-29 13:06 ` Adhemerval Zanella
0 siblings, 0 replies; 19+ messages in thread
From: Adhemerval Zanella @ 2021-01-29 13:06 UTC (permalink / raw)
To: Florian Weimer, Szabolcs Nagy via Libc-alpha
On 29/01/2021 09:31, Florian Weimer via Libc-alpha wrote:
> * Szabolcs Nagy via Libc-alpha:
>
>> hm ok i use --host=i686-linux-gnu but not build
>> may be i should add --build too.
>
> I can reproduce the issue with
>
> ../git/configure --prefix=/usr CC="gcc -m32" CXX="g++ -m32" \
> --host=i686-linux-gnu
>
> on a multilib x86-64 system. This means that I now have something to
> investigate.
I have a working solution here that add a new test-container rule to
trigger a ldconfig after container is setup.
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2021-01-29 13:06 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-28 18:47 Newer hwcap failures Adhemerval Zanella
2021-01-28 18:52 ` Adhemerval Zanella
2021-01-28 19:53 ` Florian Weimer
2021-01-28 20:01 ` Adhemerval Zanella
2021-01-28 20:21 ` Adhemerval Zanella
2021-01-28 20:30 ` Adhemerval Zanella
2021-01-28 21:23 ` Adhemerval Zanella
2021-01-28 22:03 ` DJ Delorie
2021-01-29 5:56 ` Florian Weimer
2021-01-29 6:07 ` DJ Delorie
2021-01-29 6:09 ` DJ Delorie
2021-01-29 9:20 ` Florian Weimer
2021-01-29 10:43 ` Szabolcs Nagy
2021-01-29 10:48 ` Florian Weimer
2021-01-29 10:51 ` Szabolcs Nagy
2021-01-29 11:53 ` Adhemerval Zanella
2021-01-29 12:46 ` H.J. Lu
2021-01-29 12:31 ` Florian Weimer
2021-01-29 13:06 ` Adhemerval Zanella
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).