On Sat, Nov 9, 2019 at 8:46 AM Seebs <se...@seebs.net> wrote:
> On Sat, 09 Nov 2019 16:30:41 +0000
> Richard Purdie <richard.pur...@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

With this merged, we can also drop the hack to force the sqlite static
lib to be PIC:

Openembedded-core mailing list

Reply via email to