Re: [HACKERS] [COMMITTERS] pgsql: Add port/strnlen support to libpq and ecpg Makefiles.
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.
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
