meson and pg_config --libs/--ldflags_ex

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: meson and pg_config --libs/--ldflags_ex
Date: 2024-04-14 23:41:38
Message-ID: ZhxpstcwT2vno8lT@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

While bumping on a problem with an extension that relied on pg_config
--libs, I've been recalled about the fact that pg_config produces no
output for --libs/--ldflags_ex when building with meson,
src/include/meson.build including the following on HEAD since meson
has been introduced in e6927270cd18:
var_ldflags_ex = '' # FIXME
# FIXME - some extensions might directly use symbols from one of libs. If
# that symbol isn't used by postgres, and statically linked, it'll cause an
# undefined symbol at runtime. And obviously it'll cause problems for
# executables, although those are probably less common.
var_libs = ''

A equivalent of pgxs.mk is generated when building with meson, and
it uses LIBS.

Anyway, looking at https://mesonbuild.com/Dependencies.html and our
meson.build, we rely heavily on declare_dependency() to add a library
to the internal list used in the build after some find_library()
lookups, but there is no easy way to extract that later on.

Maintaining a list in a variable built in the main meson.build may be
OK knowing that new dependencies are not added that often, but I
cannot stop thinking that there is some magic I am missing from meson
to get an access to this information once all the options are
processed.

Thoughts or comments?
--
Michael

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2024-04-14 23:47:11 Re: Stability of queryid in minor versions
Previous Message David Rowley 2024-04-14 23:38:09 Re: Fix out-of-bounds in the function GetCommandTagName