I wrote:
> On reflection, let's just go with the solution of building libpgport_lib.a
> with the right flags (fPIC + threading) and leave libpgport.a alone.
> That way we don't need a debate about whether there's an efficiency
> cost worth worrying about.
I looked into this and got discouraged aft
Andres Freund writes:
> On 2017-10-11 11:58:58 -0400, Tom Lane wrote:
>> 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.
> We already kinda are, just by copying things around ;)
Yeah.
Hi,
On 2017-10-11 11:58:58 -0400, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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,
On 2017-10-11 15:28:16 +, Tom Lane wrote:
> Add port/strnlen support to libpq and ecpg Makefiles.
>
> In the wake of fffd651e8, any makefile that pulls in snprintf.c
> from src/port/ needs to be prepared to pull in strnlen.c as well.
> Per buildfarm.
Thanks.
> Modified Files
> -
Add port/strnlen support to libpq and ecpg Makefiles.
In the wake of fffd651e8, any makefile that pulls in snprintf.c
from src/port/ needs to be prepared to pull in strnlen.c as well.
Per buildfarm.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/46912d9b1504cfaede1
