Message-ID: <b8103d16bf26cff7a393d1de690474dbd9afaa19.camel@cybertec.at>
Subject: Re: Use -fvisibility=hidden for shared libraries
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org
Date: Mon, 01 Nov 2021 05:55:40 +0100
In-Reply-To: <20211101020311.av6hphdl6xbjbuif@alap3.anarazel.de>
References: <20211101020311.av6hphdl6xbjbuif@alap3.anarazel.de>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/b8103d16bf26cff7a393d1de690474dbd9afaa19.camel%40cybertec.at>
Precedence: bulk

On Sun, 2021-10-31 at 19:03 -0700, Andres Freund wrote:
> Currently postgres builds extension shared libraries (i.e. pretty much
> everything but libpq) with global visibilty. I.e. symbols that are not
> static will be visible from outside the shared library.
> 
> On the one platform where that behaviour is not available, namely
> windows, we emulate it by analyzing the input files to the shared
> library and exporting all the symbols therein.
> 
> For the meson build [1] proposal that turned out to be a bit more
> verbose to implement than I'd liked. Thinking about the problem I
> realized that, at least I think so, there's really no good reason to
> force-export symbols in our shared libraries:
> 
> Because the number of symbols required from shared libraries is
> typically small, and the majority of the symbols are generated via
> PG_FUNCTION_INFO_V1, it isn't a lot of work to explicitly export the
> necessary symbols.

That sounds like a good idea.

I see that at least clang and gcc support this flag.

Could the reduced number of exported functions be a problem, if someone
relies on some function being exported?  It may not be worth worrying about,
and they can always come and make a case for that symbol to be exported.

Yours,
Laurenz Albe