(2014/02/18 0:02), Dave Page wrote:
On Mon, Feb 17, 2014 at 2:58 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Dave Page <dp...@pgadmin.org> writes:
On Fri, Feb 14, 2014 at 5:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
(BTW, narwhal is evidently not trying to build plpython. I wonder
why not?)
Not sure - it's certainly installed on the box. I've enabled it for
now, and will see what happens.
Sigh ... stop the presses.
In 9.3, narwhal is *still* showing a PGDLLIMPORT-type failure that no
other Windows critter is unhappy about:
dlltool --export-all --output-def worker_spi.def worker_spi.o
dllwrap -o worker_spi.dll --def worker_spi.def worker_spi.o -L../../src/port
-L../../src/common -Wl,--allow-multiple-definition -L/mingw/lib
-Wl,--as-needed -L../../src/backend -lpostgres
Info: resolving _MyBgworkerEntry by linking to __imp__MyBgworkerEntry
(auto-import)
fu000001.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname'
fu000002.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname'
nmth000000.o(.idata$4+0x0): undefined reference to `_nm__MyBgworkerEntry'
collect2: ld returned 1 exit status
So we are back to square one AFAICS: we still have no idea why narwhal
is pickier than everything else. (BTW, to save people the trouble of
looking: MyBgworkerEntry is marked PGDLLIMPORT in HEAD but not 9.3.)
Also, in HEAD narwhal is building things OK, but then seems to be
dumping core in the dblink regression test, leaving one with not a very
warm feeling about whether the contrib executables it's building are
any good.
Well, as we know, Narwhal is really quite old now. I think I built it
seven+ years ago.
There is a difference between narwhal and my pretty old machine
(Windows Vista gcc 3.4.5). Linking perl58.lib or tcl84.lib works
on my machine but neither works on narwhal. Therefore dlltool still
remains in Makefiles of plperl, pltcl and plpython (linking
pythonxx.lib doesn't work even on a newer machine).
I tried another way which links the dll directly instead of msvc
import library and got successful results on both old and newer
machines except for plpython on an old machine which fails with a
compilation error before linkage phase.
I attached a patch which eliminates pexports and dlltool from
makefile of plperl. The patch links mingw gcc import library
if it exists, otherwise links the dll directly.
When it works on narwhal, I can provide similar patches for pltcl
and plpython.
regards,
Hiroshi Inoue
diff --git a/src/pl/plperl/GNUmakefile b/src/pl/plperl/GNUmakefile
index 1e800a3..55fe9b9 100644
--- a/src/pl/plperl/GNUmakefile
+++ b/src/pl/plperl/GNUmakefile
@@ -36,23 +36,17 @@ DATA = plperl.control plperl--1.0.sql plperl--unpackaged--1.0.sql \
PERLCHUNKS = plc_perlboot.pl plc_trusted.pl
-# Perl on win32 ships with import libraries only for Microsoft Visual C++,
-# which are not compatible with mingw gcc. Therefore we need to build a
-# new import library to link with.
+# When Perl on win32 doesn't ship with mingw import libraries, link to the DLL
+# directly.
ifeq ($(PORTNAME), win32)
+perllibdir := $(subst -L,,$(filter -L%, $(perl_embed_ldflags)))
perlwithver := $(subst -l,,$(filter -l%, $(perl_embed_ldflags)))
-PERLDLL := $(dir $(subst ',,$(PERL)))$(perlwithver).dll
-# we no longer want to include the original -l spec in SHLIB_LINK
-override perl_embed_ldflags :=
-
-OBJS += lib$(perlwithver).a
-
-lib$(perlwithver).a: $(perlwithver).def
- dlltool --dllname $(perlwithver).dll --def $(perlwithver).def --output-lib lib$(perlwithver).a
-
-$(perlwithver).def: $(PERLDLL)
- pexports $^ > $@
+# Link to the perl DLL directly in the bin directory unless the mingw import
+# library exists.
+ifeq (, $(shell find $(perllibdir) -maxdepth 1 -name lib$(perlwithver).a))
+override perl_embed_ldflags := -L$(dir $(PERL))' -l$(perlwithver)
+endif
endif # win32
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
