Re: Meson far from ready on Windows

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