Andres Freund:
That's not necessarily true. The nix package manager and thus NixOS track all
dependencies for a piece of software. If any of the dependencies are updated, all
dependents are rebuilt, too. So the security concern doesn't apply here. There is a
"static overlay", which builds everything linked fully statically.
Right. There's definitely some scenario where it's ok, I was simplifying a bit.
Unfortunately, PostgreSQL doesn't build in that, so far.
I've built mostly statically linked pg without much of a problem, what trouble
did you encounter? Think there were some issues with linking Kerberos and
openldap statically, but not on postgres' side.
Mostly the "can't disable shared libraries / backend builds" part
mentioned below.
Building the postgres backend without support for dynamic linking doesn't make
sense though. Extensions are just stop ingrained part of pg.
I think there might be some limited use-cases for a fully-static
postgres backend without the ability to load extensions: Even if we get
libpq to build fine in the fully-static overlay mentioned above, a lot
of reverse dependencies have to disable tests, because they need a
running postgres server to run their tests against.
Providing a really simple postgres backend, with only minimal
functionality, would allow some basic sanity tests, even in this purely
static environment.
Lately, I have been looking into building at least libpq in that static
overlay, via Meson. There are two related config options:
-Ddefault_library=shared|static|both
-Dprefer_static
The first controls which libraries (libpq, ...) to build ourselves. The second
controls linking, IIUC also against external dependencies.
Pg by default builds a static libpq on nearly all platforms (not aix I think
and maybe not Windows when building with autoconf, not sure about the old msvc
system) today?
Yes, PG builds a static libpq today. But it's hard-to-impossible to
*disable building the shared library*. In the fully static overlay, this
causes the build to fail, because shared libraries can't be build.
Maybe it would be a first step to support -Dprefer_static?
That should work for nearly all dependencies today. Except for libintl, I
think. I found that there are a lot of buglets in static link dependencies of
various libraries though.
To support prefer_static, we'd also have to look at our internal
linking, i.e. whether for example psql is linked against libpq
statically or dynamically. Once prefer_static controls that, that's
already a step forward to be able to build more of the code-base without
shared libraries available.
Best,
Wolfgang
