Re: narwhal and PGDLLIMPORT

On Mon, Feb 17, 2014 at 2:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dave Page <dpage(at)pgadmin(dot)org> writes:
>> On Fri, Feb 14, 2014 at 5:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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. Is it really worth banging heads against walls to
support something that noone in their right mind should be using for a
build these days?

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company