Re: narwhal and PGDLLIMPORT

OK I can see the error message at PostgreSQL Build Farm Log.

I see a similar problem in a simple test case.

gcc -DCALLPG=\"import1\" -c export.c -o export1.o
dlltool --export-all --output-def export1.def export1.o
dlltool --dllname export1.exe --def export1.def --output-lib export1.a
dlltool --dllname export1.exe --output-exp export1.exp --def export1.def
gcc -o export1.exe -Wl,--base-file,export1.base export1.exp export1.o
dlltool --dllname export1.exe --base-file export1.base --output-exp
export1.exp
--def export1.def
gcc -Wl,--stack=65536 -o export1.exe export1.exp export1.o
rm -f export1.exp export1.base
gcc -DCALLPG=\"import1\" -c import.c -o import1.o
dlltool --export-all --output-def import1.def import1.o
dllwrap -o import1.dll --dllname import1.dll import1.o export1.a --def
import1.def
Info: resolving _intnum by linking to __imp__intnum (auto-import)
fu000001.o:(.idata$2+0xc): undefined reference to `export1_a_iname'
nmth000000.o:(.idata$4+0x0): undefined reference to `_nm__intnum'
collect2: ld returned 1 exit status

Adding __declspec(dllimport) fixes the problem.

Using gcc only build also fixes the problem.
gcc -DCALLPG=\"import2\" -c export.c -o export2.o
gcc -Wl,--export-all-symbols -Wl,--out-implib=export2.a -o export2
export2.o
Creating library file: export2.a
gcc -DCALLPG=\"import2\" -c import.c -o import2.o
gcc -shared -o import2.dll import2.o export2.a
-Wl,--out-implib=import2.dll.a
Info: resolving _intnum by linking to __imp__intnum (auto-import)
Creating library file: import2.dll.a
Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
tool and dlltool is almost a deprecated tool. Cygwin port is removing
the use of dllwrap and dlltool now. Isn't it better for MINGW port to
follow it?

Changing the machine from the one using gcc 3.4.5 to another one
using 4.6.1 also fixes the problem.

regards,
Hiroshi Inoue

(2014/02/07 12:25), Hiroshi Inoue wrote:
> (2014/02/05 14:52), Tom Lane wrote:
>> Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
>>> On 02/05/2014 06:29 AM, Tom Lane wrote:
>>>> I had been okay with the manual PGDLLIMPORT-sprinkling approach
>>>> (not happy with it, of course, but prepared to tolerate it) as long
>>>> as I believed the buildfarm would reliably tell us of the need for
>>>> it. That assumption has now been conclusively disproven, though.
>>
>>> I'm kind of horrified that the dynamic linker doesn't throw its toys
>>> when it sees this.
>>
>> Indeed :-(.
>>
>> The truly strange part of this is that it seems that the one Windows
>> buildfarm member that's telling the truth (or most nearly so, anyway)
>> is narwhal, which appears to have the oldest and cruftiest toolchain
>> of the lot. I'd really like to come out the other end of this
>> investigation with a clear understanding of why the newer toolchains
>> are failing to report a link problem, and yet not building working
>> executables.
>
> Is it a linkage error?
> Could you please show me the error message concretely?
>
> regards,
> Hiroshi Inoue