Re: Linking libpq statically to libssl

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

In response to

Responses

Browse pgsql-hackers by date

  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