public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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.

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