Re: [HACKERS] [COMMITTERS] pgsql: Add port/strnlen support to libpq and ecpg Makefiles.

[Tom Lane]

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-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Add port/strnlen support to libpq and ecpg Makefiles.

[Tom Lane]

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.  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-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers