Re: narwhal and PGDLLIMPORT - Mailing list pgsql-hackers
From | Hiroshi Inoue |
---|---|
Subject | Re: narwhal and PGDLLIMPORT |
Date | |
Msg-id | 52F4725A.9030207@tpf.co.jp Whole thread Raw |
In response to | Re: narwhal and PGDLLIMPORT (Hiroshi Inoue <inoue@tpf.co.jp>) |
Responses |
Re: narwhal and PGDLLIMPORT
(Tom Lane <tgl@sss.pgh.pa.us>)
|
List | pgsql-hackers |
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.ogcc -Wl,--export-all-symbols-Wl,--out-implib=export2.a -o export2 export2.oCreating library file: export2.agcc -DCALLPG=\"import2\" -c import.c -o import2.ogcc -shared -o import2.dll import2.oexport2.a -Wl,--out-implib=import2.dll.aInfo: 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@2ndquadrant.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
pgsql-hackers by date: