All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Phil Blundell" <pb@pbcl.net>
To: Andre McCurdy <armccurdy@gmail.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>,
	Rasmus Villemoes <rasmus.villemoes@prevas.dk>,
	OE Core mailing list <openembedded-core@lists.openembedded.org>,
	Martin Jansa <martin.jansa@gmail.com>,
	Khem Raj <raj.khem@gmail.com>,
	Andreas Oberritter <obi@opendreambox.org>
Subject: Re: [OE-core] [PATCH v3] glibc: move ld.so.conf back to main package
Date: Thu, 4 Jun 2020 23:04:37 +0200	[thread overview]
Message-ID: <20200604210437.GA28641@pbcl.net> (raw)
In-Reply-To: <CAJ86T=Xu+mjNER1D=R4110uN-8oK-s3xk6ij1hChESNVY2U2Dw@mail.gmail.com>

On Thu, Jun 04, 2020 at 01:05:30PM -0700, Andre McCurdy wrote:
> The fix being proposed is simply to always leave the config file in
> the rootfs, so it's always there when ldconfig is run at build time.
> Doing so seems safe enough. Since the config file is only parsed by
> ldconfig, there's no run time performance penalty of leaving it around
> - it will just be ignored if there's no ldconfig in the rootfs to use
> it.

Yes, agreed.  For some reason I had previously got it into my head
that ld.so itself would read ld.so.conf if there is no ld.so.cache,
but I just checked the glibc sources again and clearly it doesn't.
I'm not sure if my previous understanding was outdated, mixed up
with some other libc, or just plain wrong, but either way you're
right that there's no performance penalty.

I also checked with strace which reveals that, on the other hand,
ld.so _is_ trying to open /etc/ld.so.preload which is clearly a
waste of time as well.  But that's a separate issue...

p.

  reply	other threads:[~2020-06-04 21:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1614B0E5E96C4272.14405@lists.openembedded.org>
2020-06-02 12:17 ` [PATCH v3] glibc: move ld.so.conf back to main package Rasmus Villemoes
2020-06-02 17:58   ` Khem Raj
2020-06-02 19:56     ` Rasmus Villemoes
2020-06-02 20:00   ` [OE-core] " Phil Blundell
2020-06-02 20:17     ` Richard Purdie
2020-06-02 21:15       ` Phil Blundell
2020-06-02 21:46         ` Andre McCurdy
2020-06-03  7:38           ` Rasmus Villemoes
2020-06-03 20:44             ` Andre McCurdy
2020-06-04  6:57               ` Rasmus Villemoes
2020-06-04 12:43               ` Richard Purdie
2020-06-04 20:05                 ` Andre McCurdy
2020-06-04 21:04                   ` Phil Blundell [this message]
2020-06-05 10:34                   ` Rasmus Villemoes
2020-06-03 23:41           ` Khem Raj
2020-06-03  7:17         ` Rasmus Villemoes

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=20200604210437.GA28641@pbcl.net \
    --to=pb@pbcl.net \
    --cc=armccurdy@gmail.com \
    --cc=martin.jansa@gmail.com \
    --cc=obi@opendreambox.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    --cc=rasmus.villemoes@prevas.dk \
    --cc=richard.purdie@linuxfoundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.