Re: pgsql: Add port/strnlen support to libpq and ecpg Makefiles.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Add port/strnlen support to libpq and ecpg Makefiles.
Date: 2017-10-11 15:58:58
Message-ID: 20091.1507737538@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> Phew. This is a bit a sad state of affairs. The separate libpq logic for
> getting pgport is presumably because of possibly different threading
> flags and then because of the appropriate compiler/linker flags for a
> shared library?

I don't see why threading would matter, but building with -fPIC or
not is definitely an issue.

I agree the PITA factor of the current approach keeps increasing.
It sounds a bit silly to build libpgport three ways, but maybe
we should just do that.

Or conceivably we should just build the FE version of libpgport.a
with -fPIC and not worry about whether that loses some efficiency
for client programs. A lot of distros are effectively forcing
that, or even -fPIE, anyway.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2017-10-11 16:12:18 Re: pgsql: Add port/strnlen support to libpq and ecpg Makefiles.
Previous Message Andres Freund 2017-10-11 15:49:11 Re: pgsql: Add port/strnlen support to libpq and ecpg Makefiles.

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2017-10-11 16:05:32 Re: SendRowDescriptionMessage() is slow for queries with a lot of columns
Previous Message Robert Haas 2017-10-11 15:54:30 Re: parallelize queries containing initplans