meson: Allow disabling static libraries

On Tue Jan 20, 2026 at 1:04 AM CST, Peter Eisentraut wrote:

This patch allows disabling the build of static libraries using the
standard meson option -Ddefault_library=shared (defaults to "both").
This option would work out of the box if you use the library() function
to build libraries, but we use shared_library() and static_library()
separately, for reasons that are explained in
src/interfaces/libpq/meson.build. So now with this, the option works
again as expected from the end user's perspective.

This approach was suggested by Tristan Partin over in the AIX thread[0],
but I figured this could be a generally usable feature, as some
distributions don't want to build static libraries.

For illustration and continuous testing, I disabled static libraries in
the CI SanityCheck task.

Maybe a better test would be to install the build tree into a DESTDIR,
and then do a `find $DESTDIR -type f -name '*.a'` and confirm that no
static libraries were installed.

Otherwise, the patch looks good.

--
Tristan Partin
Databricks (https://databricks.com)

Hi,

On 2026-01-20 08:03:58 +0100, Peter Eisentraut wrote:

This patch allows disabling the build of static libraries using the standard
meson option -Ddefault_library=shared (defaults to "both"). This option
would work out of the box if you use the library() function to build
libraries, but we use shared_library() and static_library() separately, for
reasons that are explained in src/interfaces/libpq/meson.build. So now with
this, the option works again as expected from the end user's perspective.

This approach was suggested by Tristan Partin over in the AIX thread[0], but
I figured this could be a generally usable feature, as some distributions
don't want to build static libraries.

Makes sense to me.

For illustration and continuous testing, I disabled static libraries in the
CI SanityCheck task.

Hm. I guess that makes sense.

The opposite case of disabling shared libraries doesn't work at the moment.
I think that is much less useful, but if someone wanted to, they could
implement it in this same framework.

I suspect there are some folks interested in that, although I don't find that
a particularly interesting thing to do personally. It'd certainly a bit weird
to document, since it fundamentally won't work for the server...

###############################################################
@@ -3499,18 +3513,20 @@ endif
installed_targets = [
backend_targets,
bin_targets,
- libpq_st,
pl_targets,
contrib_targets,
nls_mo_targets,
ecpg_targets,
]
+if dep_static_lib.found()
+ installed_targets += [libpq_st]
+endif

Wonder if we ought to define installed_targets = [] earlier and allow
different meson.build files to add themselves, instead of putting knowledge
like this into a central spot.

Separately, perhaps it'd be mildly nicer to have a boolean for static libs
instead of using .found() everywhere.

Greetings,

Andres Freund

On 20.01.26 18:03, Andres Freund wrote:

###############################################################
@@ -3499,18 +3513,20 @@ endif
installed_targets = [
backend_targets,
bin_targets,
- libpq_st,
pl_targets,
contrib_targets,
nls_mo_targets,
ecpg_targets,
]
+if dep_static_lib.found()
+ installed_targets += [libpq_st]
+endif

Wonder if we ought to define installed_targets = [] earlier and allow
different meson.build files to add themselves, instead of putting knowledge
like this into a central spot.

Right. See attached patch 0001. This introduces a variable
libpq_targets and populates it in the subdirectories. This moves the
knowledge away from the top-level meson.build.

Separately, perhaps it'd be mildly nicer to have a boolean for static libs
instead of using .found() everywhere.

Yeah, after playing with this a bit more, I'm not sure sure this
disabler trick is really that good. The idea would have been that you
just need to add the disabler to the dependencies and everything else
will magically work. But the reason that you need stuff like

+if dep_static_lib.found()
+  installed_targets += [libpq_st]
+endif

is that the disabler sneaks up into other variables and dependencies and
has weird effects. For example, if you remove "if" around this and
similar lines, then "meson test" breaks in highly confusing ways
(probably because tmp_install depends on installed_targets).

So I think, since we have to have these conditionals, we might as well
put them around the whole static_library() call. And then we can use a
straightforward Boolean variable, like you suggest. See attached patch
0003 (which is on top of 0002, so it would make more sense to view the
diff 0001..0003).

This is also more robust because you get explicit errors for example if
you use libpq_st or libpq_so when they are disabled, instead of
sometimes silently doing nothing.

Peter Eisentraut <peter@eisentraut.org> writes:

On 20.01.26 18:03, Andres Freund wrote:

Separately, perhaps it'd be mildly nicer to have a boolean for static libs
instead of using .found() everywhere.

Yeah, after playing with this a bit more, I'm not sure sure this
disabler trick is really that good. The idea would have been that you
just need to add the disabler to the dependencies and everything else
will magically work. But the reason that you need stuff like
+if dep_static_lib.found()
+ installed_targets += [libpq_st]
+endif
is that the disabler sneaks up into other variables and dependencies and
has weird effects. For example, if you remove "if" around this and
similar lines, then "meson test" breaks in highly confusing ways
(probably because tmp_install depends on installed_targets).

That seems like an excellent reason to stay away from disabler()
and use your "variant 2". I reviewed/tested this and noted a couple
of other problems:

1. This doesn't work for AIX, because there we'll need to force
build_static_lib to false and yet we'll still want (by default anyway)
to install libpgcommon.a and friends. In the attached I dealt with
that by breaking build_static_lib into two variables, build_static_lib
and install_internal_static_lib.

2. As written, this resulted in installing libpgcommon_srv.a and
libpgport_srv.a, whereas historically we've only installed the
frontend and shlib variants of those libraries. I do not see a
reason to change that behavior. I fixed it in the attached with

+ 'install': install_internal_static_lib and name != '_srv',

but perhaps there's a nicer way?

I think the attached v3 is about ready to go, with perhaps two
loose ends for you to deal with:

* Do we need to document this in the SGML docs?

* Given that -Ddefault_library=static doesn't actually work and
I doubt we have any interest in ever making it work, perhaps
it would be nicer to throw an explicit 'not supported' error.
As this stands, if you try it you get
src/interfaces/libpq/meson.build:89:0: ERROR: Unknown variable "libpq_so".
which looks more like a bug than an intentionally-unsupported option.

regards, tom lane

On 18.02.26 19:39, Tom Lane wrote:

I think the attached v3 is about ready to go, with perhaps two
loose ends for you to deal with:

* Do we need to document this in the SGML docs?

* Given that -Ddefault_library=static doesn't actually work and
I doubt we have any interest in ever making it work, perhaps
it would be nicer to throw an explicit 'not supported' error.
As this stands, if you try it you get
src/interfaces/libpq/meson.build:89:0: ERROR: Unknown variable "libpq_so".
which looks more like a bug than an intentionally-unsupported option.

Committed with documentation addition and an explicit error for the
not-supported case.

Peter Eisentraut <peter@eisentraut.org> writes:

Committed with documentation addition and an explicit error for the
not-supported case.

Thanks! Barring objections, I'll get on with pushing the AIX patches.

regards, tom lane