From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Linking libpq statically to libssl |
Date: | 2017-10-27 13:37:49 |
Message-ID: | 32566.1509111469@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gilles Darold | 2017-10-27 13:38:40 | Re: proposal: schema variables |
Previous Message | Tom Lane | 2017-10-27 13:29:07 | Re: [GENERAL] Postgres 10 manual breaks links with anchors |