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.
Ifany of the dependencies are updated, all dependents are rebuilt, too. So the security concern doesn't apply here.
Thereis 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
someissues 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
ingrainedpart 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
configoptions:
 
>> -Ddefault_library=shared|static|both
>> -Dprefer_static
>>
>> The first controls which libraries (libpq, ...) to build ourselves. The second controls linking, IIUC also against
externaldependencies.
 
> 
> 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
bugletsin 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