Re: [PATCH] pseudo: Drop static linking to sqlite3

[Khem Raj <raj.khem@gmail.com>]

On Mon, 2019-11-11 at 05:04 -0800, Andre McCurdy wrote:
> On Sat, Nov 9, 2019 at 8:46 AM Seebs <seebs@seebs.net> wrote:
> > 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
> 
> With this merged, we can also drop the hack to force the sqlite
> static
> lib to be PIC:
> 
>   
> https://git.openembedded.org/openembedded-core/commit/?id=6a58e12d19c539deac9e90679a68438497a42fa4

That would be good but a caution is that if pseudo is just one usecase
here which brought this issue forward, since we use PIE by default this
would come up elsewhere too