Re: ABI Compliance Checker GSoC Project - Mailing list pgsql-hackers

From Andres Freund
Subject Re: ABI Compliance Checker GSoC Project
Date
Msg-id gerdhmywv25upplfnrerdweyzyg32ru5rakxk7d4x3nhkhvle7@ffrdd6xmuugz
Whole thread Raw
In response to Re: ABI Compliance Checker GSoC Project  (Álvaro Herrera <alvherre@kurilemu.de>)
Responses Re: ABI Compliance Checker GSoC Project
List pgsql-hackers
Hi,

On 2025-06-05 19:05:28 +0200, Álvaro Herrera wrote:
> On 2025-Jun-04, Mankirat Singh wrote:
>
> > Here's the workflow I tried to compile
> > $ ./configure CFLAGS="-Og -g -fvisibility=hidden"
> > --prefix=/home/mankirat/install/REL_17_4
> > $ make -j$(nproc)
> > ........
> > /usr/bin/ld: /home/mankirat/postgres/src/fe_utils/string_utils.c:1154:
> > undefined reference to `PQserverVersion'
> > /usr/bin/ld: /home/mankirat/postgres/src/fe_utils/string_utils.c:1156:
> > undefined reference to `appendPQExpBufferChar'
> > /usr/bin/ld: /home/mankirat/postgres/src/fe_utils/string_utils.c:1155:
> > undefined reference to `appendPQExpBufferStr'
> > /usr/bin/ld: /home/mankirat/postgres/src/fe_utils/string_utils.c:1164:
> > undefined reference to `appendPQExpBufferStr'
> > /usr/bin/ld: /home/mankirat/postgres/src/fe_utils/string_utils.c:1165:
> > undefined reference to `appendPQExpBuffer'
> > /usr/bin/ld: /home/mankirat/postgres/src/fe_utils/string_utils.c:1169:
> > undefined reference to `termPQExpBuffer'
> > /usr/bin/ld: /home/mankirat/postgres/src/fe_utils/string_utils.c:1170:
> > undefined reference to `termPQExpBuffer'
>
> Ah yeah, that doesn't work.  What confused me is that we do use
> -fvisibility=hidden in our builds already, just not in this way; what we
> do is put it in the CFLAGS specifically for "modules".  By adding it to
> the overall CFLAGS I think you're breaking things for the linker
> somehow, though I don't understand exactly how or why.

Two mechanisms, I think:

For some libraries, like libpq, we rely on export files for symbol
visibility. Just adding -fvisibility=hidden will remove the symbols from
visibility before the linker gets to them, basically making libpq not export
any symbols.

Extensions rely on linking against a vast number of symbols in the main
binary. Just adding -fvisibility=hidden will hide those symbols. I think it's
somewhat platform defined how -fvisibility=hidden will interact with
-Wl,--export-dynamic.


For "modules" it doesn't cause problems because we only rely on a small set of
functions to be visible on postgres, namely _PG_init(), the module magic and
functions exported with PG_FUNCTION_INFO_V1(). For those we all have added
explicit PGDLLEXPORT annotations, which "counteracts" the -fvisibility=hidden.

This is beneficial for extensions because on ELF platforms, all exported
platforms in shared libraries can be intercepted by the main executable,
requiring all function calls between exported functions within an extension to
go through the GOT, slowing things down noticeably.


> Anyway, it doesn't look to me like adding -fvisibility=hidden to CFLAGS is a
> viable solution, though maybe it is possible to get the build to play nice.

It'd be nice if we could get there, but it'd require annotating *all*
intentionally exported functions in the backend with PGDLLIMPORT (rather than
just doing that for variables).  Then we could make some symbols
*intentionally* not exported, which can improve the code generation (allowing
more compiler and linker optimizations).

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: What is a typical precision of gettimeofday()?
Next
From: "David E. Wheeler"
Date:
Subject: Re: ABI Compliance Checker GSoC Project