From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) by sourceware.org (Postfix) with ESMTPS id 165753851C0B for ; Fri, 29 Jan 2021 12:47:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 165753851C0B Received: by mail-ot1-x32f.google.com with SMTP id e70so8441210ote.11 for ; Fri, 29 Jan 2021 04:47:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0rPPxGS6zu72pgkvll4zjU4VKfDRKyuRmvma/ZifKGs=; b=Lv8rdiDXzOhJDjjnfKgo5s0W75E+Cna0eTAfe/0CnTLlxL8qqP0kB9gPYmpnCo1HxX NWwj9Sc45eMXBLmqkwHBTvwrCWYGpzwMV3CNXZlzMTfzLmMAqCAMy7/Zj8XlPyai6arb YuGCE9iOfgKlgOcNwbCJJxy92LLfxOWKwgOwMU1EEtD7r/uY2Sjg2KymsDG7HkbDwBVW WamTPT2bSf7uq7X9XYxmZdMSsyABM8DcifuWVKuItBCWtPGCUd5QK69WXzXY0Bn2NDbB vTwFK82IpJz16MgVDR3vzCRBw4RwWXuM7x0uZZUrgTVTh1xVz1/U5jA3wI5fas4+oaPg OdpQ== X-Gm-Message-State: AOAM532iDdxWRTaHthmoFTZaJ9uiT9NrsLZ4MOqhvYhkadI7AjC5F+MT zC6BLujPlTofXlu8/7m4xmyJcH6K98TTrnCh7qs= X-Google-Smtp-Source: ABdhPJwfiDL2HwMbQgok/5S3KsqCCgdMGXJGzjI2sGKcq3iMwBu/L1pupMS8LJchcH3wguV0rNYNsHitqDo1BeGBNXQ= X-Received: by 2002:a05:6830:1e2a:: with SMTP id t10mr2868513otr.90.1611924432480; Fri, 29 Jan 2021 04:47:12 -0800 (PST) MIME-Version: 1.0 References: <87mtws25yw.fsf@oldenburg.str.redhat.com> <87sg6kyu8j.fsf@oldenburg.str.redhat.com> <20210129104310.GU3445@arm.com> <87ft2kyq6u.fsf@oldenburg.str.redhat.com> <20210129105111.GV3445@arm.com> In-Reply-To: From: "H.J. Lu" Date: Fri, 29 Jan 2021 04:46:36 -0800 Message-ID: Subject: Re: Newer hwcap failures To: Adhemerval Zanella Cc: Szabolcs Nagy , Florian Weimer , GNU C Library Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3032.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 12:47:14 -0000 On Fri, Jan 29, 2021 at 4:30 AM Adhemerval Zanella via Libc-alpha 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_wh= ole_file > >>>>> fails and further ldconfig does not change the process map (since > >>>>> _dl_load_cache_lookup won't reload the cache after an initial failu= re). > >>>>> > >>>>> 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, neit= her > >>>>> 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 =3D 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=3D$build_alias > >> host=3D$host_alias > >> target=3D$target_alias > >> > >> # FIXME: To remove some day. > >> if test "x$host_alias" !=3D x; then > >> if test "x$build_alias" =3D x; then > >> cross_compiling=3Dmaybe > >> elif test "x$build_alias" !=3D "x$host_alias"; then > >> cross_compiling=3Dyes > >> fi > >> fi > >> > >> I configure glibc with --build=3Di686-linux-gnu, and that gives me > >> =E2=80=9Ccross-compiling =3D no=E2=80=9D in config.make. > > > > hm ok i use --host=3Di686-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=3Dx86_64-linux-gnu --host=3Di686-linux-g= nu' and > CFLAGS=3D"x86_64-glibc-linux-gnu-gcc -m32" with a multiarch gcc built wit= h > build-many-glibcs.py: I use BUILD_CC=3D"gcc" CC=3D"gcc -m32" CXX=3D"g++ -m32" CFLAGS=3D"-O2 -g -march=3Di686" /export/gnu/import/git/sources/glibc/configure --prefix=3D/usr --without-selinux --target=3Di686-linux --build=3Di686-linu= x --host=3Di686-linux --enable-hardcoded-path-in-tests to test i686 on x86-64. > $ x86_64-glibc-linux-gnu-gcc -v > [...] > Configure with: [...] --with-multilib-list=3Dm64,m32,mx32 [...] > > This results in: > > $ grep cross-compiling config.make > cross-compiling =3D 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. --=20 H.J.