On 07/04/2015 01:09 PM, Andrew Dunstan wrote:
On 07/04/2015 11:02 AM, Tom Lane wrote:
Marco Atzeri <marco.atz...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
