From: Seebs <seebs@seebs.net>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] pseudo: Drop static linking to sqlite3
Date: Sat, 9 Nov 2019 10:46:19 -0600 [thread overview]
Message-ID: <20191109104619.209d9fcd@seebsdell> (raw)
In-Reply-To: <5100e289ac8a5c4d0196e8ec77813859bb7a703d.camel@linuxfoundation.org>
On Sat, 09 Nov 2019 16:30:41 +0000
Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> I did talk briefly to Mark (also cc'd) as he wrote the original patch
> and he thought it was possibly because the client was also linking
> against sqlite3 and due to the other things the client does, that was
> problematic.
It *shouldn't* link against sqlite3. But! The commit in question refers
to RHEL5 and LD_LIBRARY_PATH, and I think that shook loose a memory:
I think at one point, we had a Crucial Bug Fix in sqlite3, in our build
system, and if we didn't statically link, there was a risk of getting
the broken version at runtime.
> The client lib doesn't and the server side should behave just like any
> other linux binary afaik so we should be ok with a dynamicly linked
> sqlite3?
Yes.
The issue here was, I believe, not "dynamically-linked sqlite3 per se",
but "dynamic linking, plus LD_LIBRARY_PATH, picking an sqlite3 which
caused us specific problems".
In the Yocto environment, I think we're reasonably sure that we always
get a clean Yocto-built sqlite3, and that *should* be fine.
So I'd say go for it, but if you see weird sqlite3 stuff that happens
only very occasionally, look at this first. :P
-s
next prev parent reply other threads:[~2019-11-09 16:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-09 15:35 [PATCH] pseudo: Drop static linking to sqlite3 Richard Purdie
2019-11-09 16:07 ` Seebs
2019-11-09 16:30 ` Richard Purdie
2019-11-09 16:46 ` Seebs [this message]
2019-11-11 13:04 ` Andre McCurdy
2019-11-11 15:59 ` Khem Raj
2019-11-11 16:36 ` Adrian Bunk
2019-11-11 17:19 ` Khem Raj
2019-11-11 14:17 ` Mark Hatle
2019-11-11 16:34 ` Seebs
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=20191109104619.209d9fcd@seebsdell \
--to=seebs@seebs.net \
--cc=openembedded-core@lists.openembedded.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox