On 11/24/21 13:55, Andres Freund wrote:
> Hi,
>
> On 2021-11-23 17:28:08 +0100, Peter Eisentraut wrote:
>> On 22.11.21 23:32, Tom Lane wrote:
>>>> The easier approach for this class of issues is to use the linker option
>>>> -Bsymbolic.
>>> I don't recall details, but we've previously rejected the idea of
>>> trying to use -Bsymbolic widely; apparently it has undesirable
>>> side-effects on some platforms. See commit message for e3d77ea6b
>>> (hopefully there's some detail in the email thread [1]). It sounds
>>> like you're not actually proposing that, but I thought it would be
>>> a good idea to note the hazard here.
>> Also, IIRC, -Bsymbolic was once frowned upon by packaging policies, since it
>> prevents use of LD_PRELOAD. I'm not sure what the current thinking there
>> is, however.
> It doesn't break some (most?) of the uses of LD_PRELOAD. In particular, it
> doesn't break things like replacing the malloc implementation. When do you
> have a symbol that you want to override *inside* your library (executables
> already bind to their own symbols at compile time)? I've seen that for
> replacing buggy functions in closed source things, but that's about it?
>
Which things does it break exactly? I have a case where a library that
is LD_PRELOADed calls PQsetSSLKeyPassHook_OpenSSL() in its constructor
function. I'd be very unhappy if that stopped working (and so would our
client).
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com