Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 10/27/17 08:24, Daniele Varrazzo wrote: > > I have a problem building binary packages for psycopg2. Binary > > packages ship with their own copies of libpq and libssl; > > Aside from the advice of "don't do that" ... > > > however if > > another python package links to libssl the library will be imported > > twice with conflicting symbols, likely resulting in a segfault (see > > https://github.com/psycopg/psycopg2/issues/543). This happens e.g. if > > a python script both connects to postgres and opens an https resource. > > ... the standard solutions to this problem are symbol versioning and > linker flags to avoid making all symbols globally available. libpq has > symbol versioning. Maybe the libssl you are using does not. Also, for > example, if you dlopen() with RTLD_LOCAL, the symbols will not be > globally available, so there should be no conflicts.
Uh, libpq doesn't actually have symbol versioning, at least not on the installed Ubuntu packages for PG10, as shown by objdump -T : 0000000000011d70 g DF .text 0000000000000054 Base PQconnectStart and we've certainly not spent effort that I've seen to try to actually make libpq work when multiple versions of libpq are linked into the same running backend. I addressed that in my comments also and I don't believe you could guarantee that things would operate correctly even with symbol versioning being used. Perhaps if you versioned your symbols with something wildly different from what's on the system and hope that what's on the system never ends up with that version then maybe it'd work, but that's quite far from the intended use-case of symbol versioning. > This needs cooperation from various different parties, and the details > will likely be platform dependent. But it's generally a solved problem. Right, it's solved when there's one source of truth for the library which is being maintained consistently and carefully. That allows multiple versions of libraries to be installed concurrently and linked into a running process at the same time, because the group maintaining those different versions of the library make sure that the symbols are versioned with appropriate versions and they make sure to not break ABI for those symbols unless they are also changing the version and putting out a new version. This was all solved with GLIBC a very long time ago, but it's a heck of a lot of work to get it right and correct, and that's when you've got a bunch of people who work on libraries all the time and carefully control all of the versions which are installed on the OS in coordination. Trying to do so when you can't control what's happing with the other library strikes me as highly likely to result in a whole lot of difficulties. Thanks! Stephen
signature.asc
Description: Digital signature
