Daniele Varrazzo <daniele.varra...@gmail.com> writes: > I have a problem building binary packages for psycopg2. Binary > packages ship with their own copies of libpq and libssl; 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.
Basically, you're doing it wrong. Shipping your own copy of libssl, rather than depending on whatever packaging the platform provides, is just asking for pain --- and not only of this sort. You're also now on the hook to update your package whenever libssl fixes a bug or a security vulnerability, which happens depressingly often. The same applies to libpq, really. You don't want to be in the business of shipping bits that you are not the originator of. When I worked at Red Hat, there was an ironclad policy against building packages that incorporated other packages statically. I would imagine that other distros have similar policies for similar reasons. Just because you *can* ignore those policies doesn't mean you *should*. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers