Thread: [COMMITTERS] pgsql: Add port/strnlen support to libpq and ecpg Makefiles.
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/46912d9b1504cfaede1b22811039028a75f76ab8 Modified Files -------------- src/interfaces/ecpg/compatlib/.gitignore | 1 + src/interfaces/ecpg/compatlib/Makefile | 6 +++--- src/interfaces/ecpg/ecpglib/.gitignore | 1 + src/interfaces/ecpg/ecpglib/Makefile | 7 ++++--- src/interfaces/ecpg/pgtypeslib/.gitignore | 1 + src/interfaces/ecpg/pgtypeslib/Makefile | 7 ++++--- src/interfaces/libpq/.gitignore | 1 + src/interfaces/libpq/Makefile | 6 +++--- 8 files changed, 18 insertions(+), 12 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Add port/strnlen support to libpq and ecpgMakefiles.
From
Andres Freund
Date:
On 2017-10-11 15:28:16 +0000, 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
> --------------
> src/interfaces/ecpg/compatlib/.gitignore | 1 +
> src/interfaces/ecpg/compatlib/Makefile | 6 +++---
> src/interfaces/ecpg/ecpglib/.gitignore | 1 +
> src/interfaces/ecpg/ecpglib/Makefile | 7 ++++---
> src/interfaces/ecpg/pgtypeslib/.gitignore | 1 +
> src/interfaces/ecpg/pgtypeslib/Makefile | 7 ++++---
> src/interfaces/libpq/.gitignore | 1 +
> src/interfaces/libpq/Makefile | 6 +++---
> 8 files changed, 18 insertions(+), 12 deletions(-)
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?
Wonder if we shouldn't have variants of libpqport that support threading
and shared libraries, but built centrally. libpgport{-shared}{-mt} or
such. Formally speaking it's not quite right that we don't use
threading aware flags in pgbench for example. Some gcc platforms at
least pretty much assume everything is built with -pthread e.g.
Greetings,
Andres Freund
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Andres Freund <andres@anarazel.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
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Add port/strnlen support to libpq and ecpgMakefiles.
From
Andres Freund
Date:
Hi, On 2017-10-11 11:58:58 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.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. -pthread changes some "memory model" type assumptions by the compiler too IIRC, not just linker stage things. In a non-threaded environment the compiler is kinda free to invent phantom stores and such. It's unlikely to matter for just pgbench, but ... > 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 ;) > 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. Hm. Greetings, Andres Freund -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Andres Freund <andres@anarazel.de> 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. I hadn't realized how much duplication of effort is happening
within ecpg. This was a somewhat reasonable solution when it was
first invented for libpq only, but building snprintf.o four times
is pretty silly.
>> 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.
> Hm.
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.
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Re: [HACKERS] [COMMITTERS] pgsql: Add port/strnlen support to libpq and ecpg Makefiles.
From
Tom Lane
Date:
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 after realizing that not only does
libpq pull in and recompile a bundle of src/port/ files, but also from
src/common/, and even some random backend files like encnames.c and
wchar.c. We could possibly apply the same build-a-third-way technique to
src/common/, but we'd still end up with messiness for the encoding files.
Perhaps what this is telling us is that encnames.c and wchar.c ought to be
moved to src/common/.
On top of that, there are also some interactions with the MSVC build
system that I don't especially want to debug or untangle.
In short, this is looking like a whole lot more work than we could
ever hope to save by not having to maintain these file lists anymore.
So I'm not planning to pursue it. If someone else wants to, though,
have at it.
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers