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
