On 07/04/2015 11:02 AM, Tom Lane wrote:
> Marco Atzeri <marco.atzeri@gmail.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.
>
>
Windows finds the DLL in its path. I just tested this by removing the
intree pl DLLs after installing and then running contrib installcheck,
and it worked fine. Whether or not it actually loads the DLL twice when
it can find the intree DLL I don't know for sure, maybe someone with
more Windows-fu than me can inform our ignorance.
cheers
andrew