On 07/04/2015 01:09 PM, Andrew Dunstan wrote:
>
> 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.
>
BTW, the .a files being linked to above are not like Unix .a static
archives - they are import library files, which I think they are only
used at link time, not run time. The path to the DLLs isn't being hardcoded.
Unless there is further argument I propose to commit something very like
Marco's suggestion for hstore_plperl, hstore_plpython and ltree_plpython
cheers
andrew