From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: Simon Chopin <simon.chopin@canonical.com>, libc-alpha@sourceware.org
Subject: Re: [PATCH] test-container: disable ld.so system cache on DSO detection
Date: Mon, 23 Oct 2023 11:08:22 -0300 [thread overview]
Message-ID: <61a5a5b7-9b75-4892-9cf5-6c0bb999ae85@linaro.org> (raw)
In-Reply-To: <CAOOWow3PSzwdNwxyqNt7Qdy5g1oE1MOWtMPOdmTbLOwOzwBhVw@mail.gmail.com>
On 23/10/23 07:11, Simon Chopin wrote:
> Hi!
>
> Quoting Adhemerval Zanella Netto (2023-10-17 16:48:55)
>>
>>
>> On 05/10/23 09:54, Simon Chopin wrote:
>>> When building the testroot, the script runs the newly built ld.so on a
>>> couple of binaries in order to copy over any additional libararies
>>
>> s/libararies/libraries
>>
>>> needed. However, if the dependencies are found in the system cache, it
>>> will be copied over using that path.
>>>
>>> This is problematic if the system ld.so and the one built don't have the
>>> exact same search configuration. We encountered this in Ubuntu, where we
>>> build a variant of libc with -fno-omit-frame-pointer for accurate
>>> performance profiling.
>>>
>>> This variant is built using a non-standard slibdir to be able to be
>>> co-installed with the default library (e.g. slibdir = /lib/libc6-prof).
>>> Since we have /lib pointing to /usr/lib, any additional dependency
>>> should still be reachable via /usr. However, resolving via the cache
>>> might result in the additional DSOs being copied into $testroot/lib, out
>>> of the search path in the container.
>>>
>>> The problem has been triggered by 1d5024f4f052c12e404d42d3b5bfe9c3e9fd27c4
>>> ("support: Build with exceptions and asynchronous unwind tables [BZ #30587]")
>>> which introduced a dependency on libgcc_s.so.1 under some circumstances.
>>>
>>> Downstream bug: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2031495
>>
>> It makes sense to inhibit cache on testroot creation, although default
>> system dirs will always be used.
>>
>> LGTM, thanks.
>>
>> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
>
> Sorry, my experience of ML-based contributions is pretty limited. Am I
> expected to send a V2 to fix the typo in the commit log?
>
> If I need to send a V2, should it include the Reviewed-by tag?
No need, I will commit in your behalf with the commit message fixed.
prev parent reply other threads:[~2023-10-23 14:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 12:54 Simon Chopin
2023-10-17 14:48 ` Adhemerval Zanella Netto
2023-10-23 10:11 ` Simon Chopin
2023-10-23 14:08 ` Adhemerval Zanella Netto [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=61a5a5b7-9b75-4892-9cf5-6c0bb999ae85@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
--cc=simon.chopin@canonical.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).