Newer hwcap failures

Newer hwcap failures

[Adhemerval Zanella]

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?

Re: Newer hwcap failures

[Adhemerval Zanella]

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.

Re: Newer hwcap failures

[Florian Weimer]

* 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

Re: Newer hwcap failures

[Adhemerval Zanella]

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.

Re: Newer hwcap failures

[Adhemerval Zanella]

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.

Re: Newer hwcap failures

[Adhemerval Zanella]

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.

Re: Newer hwcap failures

[Adhemerval Zanella]

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.

Re: Newer hwcap failures

[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...

Re: Newer hwcap failures

[Florian Weimer]

* 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

Re: Newer hwcap failures

[DJ Delorie]

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 ;-)

Re: Newer hwcap failures

[DJ Delorie]

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.

Re: Newer hwcap failures

[Florian Weimer]

* 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

Re: Newer hwcap failures

[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.

Re: Newer hwcap failures

[Florian Weimer]

* 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

Re: Newer hwcap failures

[Szabolcs Nagy]

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)

Re: Newer hwcap failures

[Adhemerval Zanella]

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.

Re: Newer hwcap failures

[H.J. Lu]

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.

Re: Newer hwcap failures

[Florian Weimer]

* 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

Re: Newer hwcap failures

[Adhemerval Zanella]

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.