(2014/02/18 0:02), Dave Page wrote:
> On Mon, Feb 17, 2014 at 2:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Dave Page <dpage@pgadmin.org> writes:
>>> On Fri, Feb 14, 2014 at 5:32 PM, Tom Lane <tgl@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
>
>
