Re: PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

Marco Atzeri <marco(dot)atzeri(at)gmail(dot)com> writes:
> for what I see the hstore_plperl link has a double problem.
> It requires a link to hstore
> as it also requires a link to perl.
> Attached patch for solving this and a similar issue with python.

> +ifeq ($(PORTNAME), cygwin)
> +# This means we need an in-tree build on Windows, not a pgxs build
> +SHLIB_LINK += -L../hstore -lhstore -L$(perl_archlibexp)/CORE -lperl
> +endif
> [ and likewise for the other contrib transform modules ]

I wondered how come we had not seen this problem in the buildfarm,
but the answer appears to be that our only working Cygwin critter
(brolga) doesn't build any of the optional PLs, so it skips these
modules altogether. Seems like we need to improve that situation.

Also, I noted that the "regular win32" path in these makefiles
says, eg,

ifeq ($(PORTNAME), win32)
# these settings are the same as for plperl
override CPPFLAGS += -DPLPERL_HAVE_UID_GID -Wno-comment
# This means we need an in-tree build on Windows, not a pgxs build
SHLIB_LINK += ../hstore/libhstore.a $(wildcard ../../src/pl/plperl/libperl*.a)
endif

It's not apparent to me how that works at all. It seems to specify
hard-linking a copy of hstore as well as a copy of plperl into the
shlib for hstore_plperl. Then at runtime, there will *also* be the
hstore and plperl shlibs in memory. At best that means substantial
memory bloat, but it seems likely to me that it would fail altogether,
particular for plperl which has got a substantial amount of semantically-
important static storage. Two copies of that storage will not end well.

regards, tom lane