Re: pgsql: Default to hidden visibility for extension libraries where possi

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Default to hidden visibility for extension libraries where possi
Date: 2022-07-19 03:26:58
Message-ID: CAFj8pRCQ6TAJD=sP8-oOKA0BGhpUMPzUFsZQfAbW=fwssnqzig@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Hi

po 18. 7. 2022 v 3:06 odesílatel Andres Freund <andres(at)anarazel(dot)de> napsal:

> Default to hidden visibility for extension libraries where possible
>
> Until now postgres built extension libraries with global visibility, i.e.
> exporting all symbols. On the one platform where that behavior is not
> natively available, namely windows, we emulate it by analyzing the input
> files
> to the shared library and exporting all the symbols therein.
>
> Not exporting all symbols is actually desirable, as it can improve loading
> speed, reduces the likelihood of symbol conflicts and can improve intra
> extension library function call performance. It also makes the non-windows
> builds more similar to windows builds.
>
> Additionally, with meson implementing the export-all-symbols behavior for
> windows, turns out to be more verbose than desirable.
>
> This patch adds support for hiding symbols by default and, to counteract
> that,
> explicit symbol visibility annotation for compilers that support
> __attribute__((visibility("default"))) and -fvisibility=hidden. That is
> expected to be most, if not all, compilers except msvc (for which we
> already
> support explicit symbol export annotations).
>
> Now that extension library symbols are explicitly exported, we don't need
> to
> export all symbols on windows anymore, hence remove that behavior from
> src/tools/msvc. The supporting code can't be removed, as we still need to
> export all symbols from the main postgres binary.
>
> Author: Andres Freund <andres(at)anarazel(dot)de>
> Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Discussion:
> https://postgr.es/m/20211101020311.av6hphdl6xbjbuif@alap3.anarazel.de
>
>
Unfortunately, this commit definitely breaks plpgsql_check. Can the
following routines be visible?

AssertVariableIsOfType(&plpgsql_build_datatype,
plpgsql_check__build_datatype_t);
plpgsql_check__build_datatype_p = (plpgsql_check__build_datatype_t)
LOAD_EXTERNAL_FUNCTION("$libdir/plpgsql", "plpgsql_build_datatype");

AssertVariableIsOfType(&plpgsql_compile, plpgsql_check__compile_t);
plpgsql_check__compile_p = (plpgsql_check__compile_t)
LOAD_EXTERNAL_FUNCTION("$libdir/plpgsql", "plpgsql_compile");

AssertVariableIsOfType(&plpgsql_parser_setup,
plpgsql_check__parser_setup_t);
plpgsql_check__parser_setup_p = (plpgsql_check__parser_setup_t)
LOAD_EXTERNAL_FUNCTION("$libdir/plpgsql", "plpgsql_parser_setup");

AssertVariableIsOfType(&plpgsql_stmt_typename,
plpgsql_check__stmt_typename_t);
plpgsql_check__stmt_typename_p = (plpgsql_check__stmt_typename_t)
LOAD_EXTERNAL_FUNCTION("$libdir/plpgsql", "plpgsql_stmt_typename");

AssertVariableIsOfType(&plpgsql_exec_get_datum_type,
plpgsql_check__exec_get_datum_type_t);
plpgsql_check__exec_get_datum_type_p =
(plpgsql_check__exec_get_datum_type_t)
LOAD_EXTERNAL_FUNCTION("$libdir/plpgsql",
"plpgsql_exec_get_datum_type");

AssertVariableIsOfType(&plpgsql_recognize_err_condition,
plpgsql_check__recognize_err_condition_t);
plpgsql_check__recognize_err_condition_p =
(plpgsql_check__recognize_err_condition_t)
LOAD_EXTERNAL_FUNCTION("$libdir/plpgsql",
"plpgsql_recognize_err_condition");

AssertVariableIsOfType(&plpgsql_ns_lookup, plpgsql_check__ns_lookup_t);
plpgsql_check__ns_lookup_p = (plpgsql_check__ns_lookup_t)
LOAD_EXTERNAL_FUNCTION("$libdir/plpgsql", "plpgsql_ns_lookup");

Regards

Pavel

> Branch
> ------
> master
>
> Details
> -------
>
> https://git.postgresql.org/pg/commitdiff/089480c077056fc20fa8d8f5a3032a9dcf5ed812
>
> Modified Files
> --------------
> configure | 152
> +++++++++++++++++++++++++++++++++++++++++++++
> configure.ac | 13 ++++
> src/Makefile.global.in | 3 +
> src/Makefile.shlib | 13 ++++
> src/include/c.h | 13 ++--
> src/include/pg_config.h.in | 3 +
> src/makefiles/pgxs.mk | 5 +-
> src/tools/msvc/Project.pm | 7 ---
> src/tools/msvc/Solution.pm | 1 +
> 9 files changed, 198 insertions(+), 12 deletions(-)
>
>

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2022-07-19 05:33:44 pgsql: Convert macros to static inline functions (itup.h)
Previous Message Michael Paquier 2022-07-19 02:46:33 pgsql: Rework logic and simplify syntax of REINDEX DATABASE/SYSTEM

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-07-19 03:43:56 Re: Allowing REINDEX to have an optional name
Previous Message David G. Johnston 2022-07-19 03:22:44 Re: Doc about how to set max_wal_senders when setting minimal wal_level