Re: Reduce the number of special cases to build contrib modules on windows - Mailing list pgsql-hackers

From David Rowley
Subject Re: Reduce the number of special cases to build contrib modules on windows
Date
Msg-id CAApHDvpXoav0aZnsji-ZNdo=9TXqAwnwmSh44gyn8K7i2PRwJg@mail.gmail.com
Whole thread Raw
In response to Re: Reduce the number of special cases to build contrib modules on windows  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Reduce the number of special cases to build contrib modules on windows  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: Reduce the number of special cases to build contrib modules on windows  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers
On Wed, 3 Mar 2021 at 22:37, David Rowley <dgrowleyml@gmail.com> wrote:
> I've attached a rebased patch.

I've rebased this again.

I also moved away from using hash tables for storing references and
libraries.  I was having some problems getting psql to compile due to
the order of the dependencies being reversed due to the order being at
the mercy of Perl's hash function. There's mention of this in
Makefile.global.in:

# libpq_pgport is for use by client executables (not libraries) that use libpq.
# We force clients to pull symbols from the non-shared libraries libpgport
# and libpgcommon rather than pulling some libpgport symbols from libpq just
# because libpq uses those functions too.  This makes applications less
# dependent on changes in libpq's usage of pgport (on platforms where we
# don't have symbol export control for libpq).  To do this we link to
# pgport before libpq.  This does cause duplicate -lpgport's to appear
# on client link lines, since that also appears in $(LIBS).
# libpq_pgport_shlib is the same idea, but for use in client shared libraries.

I switched these back to arrays but added an additional check to only
add new items to the array if we don't already have an element with
the same value.

I've attached the diffs in the *.vcxproj files between patched and unpatched.

David

Attachment

pgsql-hackers by date:

Previous
From: Chengxi Sun
Date:
Subject: Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Next
From: Michael Paquier
Date:
Subject: Re: Table refer leak in logical replication