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

[Seebs <seebs@seebs.net>]

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'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.

> 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.

> 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.

-s