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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Sat, 2019-11-09 at 10:07 -0600, Seebs wrote:
> On Sat,  9 Nov 2019 15:35:59 +0000
> Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> > Back in 2010[1] we made pseudo statically link against sqlite3.
> > Since then the world has changed, pseudo now has separate processes
> > for the database in the server and the client and they have
> > separate linking commands.
> 
> I'm not sure what that has to do with the reasons for it being
> static? Not that I remember exactly anymore, but I think we were
> hitting problems caused if pseudo was dynamically linked to sqlite,
> but I don't remember what they were.

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.

> I'm not entirely sure I know what you mean by "separate processes for
> the database in the server and the client". I don't think
> libpseudo.so should ever do any database things at all, and it
> shouldn't need to link to sqlite.

I was under the impression the client may once have linked against it.
I admit I didn't dive into history, just checked that it clearly
doesn't now.

> > which occurs if sqlite3-native was built on a machine with glibc
> > 2.28 or later and pseudo-native is being built on glibc before
> > that.
> 
> I don't think pseudo's ever been *expected* to work when built linked
> against things built against different libc. It is *way* too full of
> unholy magics that depend on knowing which libc it's using. That
> said, the pseudo server also shouldn't really need to be statically-
> linked, the only times it ever runs under pseudo, it just immediately
> tries to escape and not run that way.

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?

> > There appears to be no easy way to avoid this other than adding a
> > copy of sqlite3 into the pseudo recipe. Given the static linking
> > doesn't seem to be required any longer due to the separate
> > processes,
> > drop that to fix those issues.
> 
> I don't understand the "separate processes" thing. So far as I know,
> pseudo has never talked to sqlite from the client. I think Jason
> Wessel had experimental patches at one point to do client-local
> sqlite work to avoid the IPC overhead, but I don't think it ever got
> merged because it turns out the IPC overhead is insignificant
> compared to everything else.

If I'm working off incorrect assumptions, is there another reason we
need a static sqlite? I have tested this patch before I posted it and
it seems fine in our test builds...

Cheers,

Richard