Thread: pgevent warnings on mingw
I just noticed these warnings on pgevent/mingw. I guess we've probably been living with it for years, but it would be nice to get it clean. (There are also some similar warnings earlier in the build regarding RegisterWaitForSingleObject.) dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o Warning: resolving _DllUnregisterServer by linking to _DllUnregisterServer@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 Warning: resolving _DllUnregisterServer by linking to _DllUnregisterServer@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 What do we have to do to clean this stuff up? cheers andrew
Andrew Dunstan wrote: > > I just noticed these warnings on pgevent/mingw. I guess we've probably > been living with it for years, but it would be nice to get it clean. > (There are also some similar warnings earlier in the build regarding > RegisterWaitForSingleObject.) > > dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o > Warning: resolving _DllUnregisterServer by linking to > _DllUnregisterServer@0 > Use --enable-stdcall-fixup to disable these warnings > Use --disable-stdcall-fixup to disable these fixups > Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 > Warning: resolving _DllUnregisterServer by linking to > _DllUnregisterServer@0 > Use --enable-stdcall-fixup to disable these warnings > Use --disable-stdcall-fixup to disable these fixups > Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 > > What do we have to do to clean this stuff up? Yeah, they've been there forever. This happened, IIRC, when we changed the files to actually do what the documentation says. The commit message is: "2) Change the pgevent DLL file so it doens't specify ordinal for the functions. You're not supposed to do that. You're actually supposed to declare them as PRIVATE as well, but mingw doesn't support that. VC++ will throw a warning and not an error though, so we can live with it. " The change was required to build at all with MSVC. //Magnus
Hi. >> dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o >> Warning: resolving _DllUnregisterServer by linking to >> _DllUnregisterServer@0 >> Use --enable-stdcall-fixup to disable these warnings >> Use --disable-stdcall-fixup to disable these fixups >> Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 >> Warning: resolving _DllUnregisterServer by linking to >> _DllUnregisterServer@0 >> Use --enable-stdcall-fixup to disable these warnings >> Use --disable-stdcall-fixup to disable these fixups >> Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 >> >> What do we have to do to clean this stuff up? I was solved for Marko-san at the time of the work of pgbouncer, and obtained the solution. The patch is this. == Before == $ make gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -I../../../src/include -I/C/work/MinGW_WORK/include -I./src/include/port/win32 -DEXEC_BACKEND "-I../../../src/include/port/win32" -c -o pgevent.o pgevent.c sed -e 's;FILEDESC;"Eventlog message formatter";' -e 's;VFT_APP;VFT_DLL;' -e 's;_ICO_;;' -e 's;\(VERSION.*\),0 *$;\1,'`date '+%y%j' | sed 's/^0*//'`';' ../../../src/port/win32ver.rc >win32ver.rc windres pgmsgevent.rc -o pgmsgevent.o --include-dir=../../../src/include --include-dir=../../../src/include --include-dir=. dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o Warning: resolving _DllUnregisterServer by linking to _DllUnregisterServer@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 Warning: resolving _DllUnregisterServer by linking to _DllUnregisterServer@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 == After patch. == $ make gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -I../../../src/include -I/C/work/MinGW_WORK/include -I./src/include/port/win32 -DEXEC_BACKEND "-I../../../src/include/port/win32" -c -o pgevent.o pgevent.c sed -e 's;FILEDESC;"Eventlog message formatter";' -e 's;VFT_APP;VFT_DLL;' -e 's;_ICO_;;' -e 's;\(VERSION.*\),0 *$;\1,'`date '+%y%j' | sed 's/^0*//'`';' ../../../src/port/win32ver.rc >win32ver.rc windres pgmsgevent.rc -o pgmsgevent.o --include-dir=../../../src/include --include-dir=../../../src/include --include-dir=. dlltool --export-all-symbols -A --output-def pgevent.def pgevent.o pgmsgevent.o dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o == It will be great if this is taken into consideration. Regards, Hiroshi Saito
Attachment
Hiroshi Saito wrote: > Hi. > >>> dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o >>> Warning: resolving _DllUnregisterServer by linking to >>> _DllUnregisterServer@0 >>> Use --enable-stdcall-fixup to disable these warnings >>> Use --disable-stdcall-fixup to disable these fixups >>> Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 >>> Warning: resolving _DllUnregisterServer by linking to >>> _DllUnregisterServer@0 >>> Use --enable-stdcall-fixup to disable these warnings >>> Use --disable-stdcall-fixup to disable these fixups >>> Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 >>> >>> What do we have to do to clean this stuff up? > > I was solved for Marko-san at the time of the work of pgbouncer, and > obtained the solution. > The patch is this. This appears to be exactly what you are *not* supposed to do. Which is assign an ordinal. See: http://msdn.microsoft.com/en-us/library/8e705t74(VS.71).aspx (that's just about the warning, there is a page somewhere with more details, but I can't find it right now) //Magnus
Hi. Sorry, I was not able to find the point to which you point. > This appears to be exactly what you are *not* supposed to do. Which is > assign an ordinal. See: > http://msdn.microsoft.com/en-us/library/8e705t74(VS.71).aspx > > (that's just about the warning, there is a page somewhere with more > details, but I can't find it right now) Please see this, if the point which you suggest becomes about output image size. == Before == -rwxr-xr-x 1 HIROSHI Administ 425977 Feb 1 00:33 pgevent.dll == After patch. == -rwxr-xr-x 1 HIROSHI Administ 425955 Feb 1 00:34 pgevent.dll Then, new pgevent.def is this. ; C:\MinGW\bin\dlltool.exe --export-all-symbols -A --output-def pgevent.def pgevent.o pgmsgevent.o EXPORTS DllRegisterServer@0 @ 1 DllUnregisterServer = DllUnregisterServer@0 @ 2 DllUnregisterServer@0 @3 g_module @ 4 DATA DllRegisterServer = DllRegisterServer@0 @ 5 Regards, Hiroshi Saito
On 1/31/09, Magnus Hagander <magnus@hagander.net> wrote: > Hiroshi Saito wrote: > > Hi. > > > >>> dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o > >>> Warning: resolving _DllUnregisterServer by linking to > >>> _DllUnregisterServer@0 > >>> Use --enable-stdcall-fixup to disable these warnings > >>> Use --disable-stdcall-fixup to disable these fixups > >>> Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 > >>> Warning: resolving _DllUnregisterServer by linking to > >>> _DllUnregisterServer@0 > >>> Use --enable-stdcall-fixup to disable these warnings > >>> Use --disable-stdcall-fixup to disable these fixups > >>> Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 > >>> > >>> What do we have to do to clean this stuff up? > > > > I was solved for Marko-san at the time of the work of pgbouncer, and > > obtained the solution. > > The patch is this. > > > This appears to be exactly what you are *not* supposed to do. Which is > assign an ordinal. See: > http://msdn.microsoft.com/en-us/library/8e705t74(VS.71).aspx AFAICS by default the mingw assigns the ordinal anyway? So whats your point? > (that's just about the warning, there is a page somewhere with more > details, but I can't find it right now) I found this: http://www.geocities.com/yongweiwu/stdcall.htm which definitely has too much detail... -- marko
On 1/31/09, Marko Kreen <markokr@gmail.com> wrote: > On 1/31/09, Magnus Hagander <magnus@hagander.net> wrote: > > Hiroshi Saito wrote: > > > Hi. > > > > > >>> dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o > > >>> Warning: resolving _DllUnregisterServer by linking to > > >>> _DllUnregisterServer@0 > > >>> Use --enable-stdcall-fixup to disable these warnings > > >>> Use --disable-stdcall-fixup to disable these fixups > > >>> Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 > > >>> Warning: resolving _DllUnregisterServer by linking to > > >>> _DllUnregisterServer@0 > > >>> Use --enable-stdcall-fixup to disable these warnings > > >>> Use --disable-stdcall-fixup to disable these fixups > > >>> Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 > > >>> > > >>> What do we have to do to clean this stuff up? > > > > > > I was solved for Marko-san at the time of the work of pgbouncer, and > > > obtained the solution. > > > The patch is this. > > > > > > This appears to be exactly what you are *not* supposed to do. Which is > > assign an ordinal. See: > > http://msdn.microsoft.com/en-us/library/8e705t74(VS.71).aspx > > > AFAICS by default the mingw assigns the ordinal anyway? > > So whats your point? FWIW, I experimented with various approaches on DLL generation, and my theory is now that numeric slot is mandatory for export, name slot optional. And what the above link above warns about is that if you manually assign a numeric slot, you may create gaps in slot table, thus resulting in larger image. But this assumes you already have slots that are manually assigned, which should not happen with pgevent.dll. Does it sound sane? With pgbouncer I used "dlltool --export-all-symbols -A" to generate the .def file, thus the slots are actually assigned automatically by dlltool, so no gap problems should arise. As Postgres does not generate .def automatically, thus Hiroshi simply posted the resulting .def file, which should not have gap problems. But such detailed .def avoids the confusing warnings from dllwrap. If you are worried about gap problems I suggest instead doing the same and making the .def file auto-generated. -- marko ps. I suggest also tagging the "g_module" as static.
Hi. I am checking that consider sufficient test as Marko-san and it is satisfactory. However, That there is a portion which does not suit the solution of MSVC also understands. Therefore, How is this proposal? 1. )remove pgevent.def It is always generated. 2.) improvement of the Makefile and Solution.pm What do you think? Regards, Hiroshi Saito ----- Original Message ----- From: "Marko Kreen" <markokr@gmail.com> > On 1/31/09, Marko Kreen <markokr@gmail.com> wrote: >> On 1/31/09, Magnus Hagander <magnus@hagander.net> wrote: >> > Hiroshi Saito wrote: >> > > Hi. >> > > >> > >>> dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o >> > >>> Warning: resolving _DllUnregisterServer by linking to >> > >>> _DllUnregisterServer@0 >> > >>> Use --enable-stdcall-fixup to disable these warnings >> > >>> Use --disable-stdcall-fixup to disable these fixups >> > >>> Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 >> > >>> Warning: resolving _DllUnregisterServer by linking to >> > >>> _DllUnregisterServer@0 >> > >>> Use --enable-stdcall-fixup to disable these warnings >> > >>> Use --disable-stdcall-fixup to disable these fixups >> > >>> Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 >> > >>> >> > >>> What do we have to do to clean this stuff up? >> > > >> > > I was solved for Marko-san at the time of the work of pgbouncer, and >> > > obtained the solution. >> > > The patch is this. >> > >> > >> > This appears to be exactly what you are *not* supposed to do. Which is >> > assign an ordinal. See: >> > http://msdn.microsoft.com/en-us/library/8e705t74(VS.71).aspx >> >> >> AFAICS by default the mingw assigns the ordinal anyway? >> >> So whats your point? > > FWIW, I experimented with various approaches on DLL generation, > and my theory is now that numeric slot is mandatory for export, > name slot optional. And what the above link above warns about > is that if you manually assign a numeric slot, you may create gaps in > slot table, thus resulting in larger image. But this assumes > you already have slots that are manually assigned, which should > not happen with pgevent.dll. > > Does it sound sane? > > With pgbouncer I used "dlltool --export-all-symbols -A" to generate > the .def file, thus the slots are actually assigned automatically > by dlltool, so no gap problems should arise. As Postgres does not > generate .def automatically, thus Hiroshi simply posted the resulting > .def file, which should not have gap problems. > > But such detailed .def avoids the confusing warnings from dllwrap. > If you are worried about gap problems I suggest instead doing the > same and making the .def file auto-generated. > > -- > marko > > ps. I suggest also tagging the "g_module" as static. > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
Ooops, sorry., One mistake:-( Please this. ----- Original Message ----- From: "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> > Hi. > > I am checking that consider sufficient test as Marko-san and it is satisfactory. > However, That there is a portion which does not suit the solution of MSVC > also understands. Therefore, How is this proposal? > > 1. )remove pgevent.def > It is always generated. > > 2.) improvement of the Makefile and Solution.pm > > What do you think? > > Regards, > Hiroshi Saito
Attachment
Ahh, sorry..like the spam.... again! I thought over that the existing msvc the did not have uneasines. so, I wish to make it this as correspondence with worried Magnus-san. It is after sufficient test. Regards, Hiroshi Saito ----- Original Message ----- From: "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> > Ooops, sorry., One mistake:-( > Please this. > > ----- Original Message ----- > From: "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> > > >> Hi. >> >> I am checking that consider sufficient test as Marko-san and it is satisfactory. >> However, That there is a portion which does not suit the solution of MSVC >> also understands. Therefore, How is this proposal? >> >> 1. )remove pgevent.def >> It is always generated. >> >> 2.) improvement of the Makefile and Solution.pm >> >> What do you think? >> >> Regards, >> Hiroshi Saito > -------------------------------------------------------------------------------- > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
Attachment
Hiroshi Saito wrote: > Ahh, sorry..like the spam.... > again! > > I thought over that the existing msvc the did not have uneasines. > so, I wish to make it this as correspondence with worried Magnus-san. > It is after sufficient test. If I read this patch right, it does an "export all symbols" when run on mingw? That surely can't be right? We may not have any additional symbols there now, but it's certaily not the intention? Plus, it makes msvc behave differently from mingw (since msvc uses the exports.txt)? I did some more checking, and it seems MS has changed the warnings in the new version of VIsual Studio. Right now, the following exports.txt file passes without warnings. Can someone check if it does on mingw? EXPORTSDllUnregisterServer @ 1;DllRegisterServer @ 2; Do you need all that extra decoration junk on mingw, or does it work this way? //Magnus
----- Original Message ----- From: "Magnus Hagander" <magnus@hagander.net> > Hiroshi Saito wrote: >> Ahh, sorry..like the spam.... >> again! >> >> I thought over that the existing msvc the did not have uneasines. >> so, I wish to make it this as correspondence with worried Magnus-san. >> It is after sufficient test. > > If I read this patch right, it does an "export all symbols" when run on > mingw? That surely can't be right? We may not have any additional > symbols there now, but it's certaily not the intention? Plus, it makes > msvc behave differently from mingw (since msvc uses the exports.txt)? > > I did some more checking, and it seems MS has changed the warnings in > the new version of VIsual Studio. Right now, the following exports.txt > file passes without warnings. Can someone check if it does on mingw? > > EXPORTS > DllUnregisterServer @ 1; > DllRegisterServer @ 2; > > > Do you need all that extra decoration junk on mingw, or does it work > this way? It was checked. $ cat pgevent.def EXPORTS DllUnregisterServer @ 1; DllRegisterServer @ 2; $ make gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv-g -I../../../src/include -I/C/work/MinGW_WORK/include -I./src/include/port/win32 -DEXEC_BACKEND "-I../../../src/include/port/win32" -c -o pgevent.o pgevent.c sed -e 's;FILEDESC;"Eventlog message formatter";' -e 's;VFT_APP;VFT_DLL;' -e 's;_ICO_;;' -e 's;\(VERSION.*\),0 *$;\1,'`date '+%y%j' | sed 's/^0*//'`';' ../../../src/port/win32ver.rc >win32ver.rc windres pgmsgevent.rc -o pgmsgevent.o --include-dir=../../../src/include --include-dir=../../../src/include --include-dir=. dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o Warning: resolving _DllUnregisterServer by linking to _DllUnregisterServer@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 Warning: resolving _DllUnregisterServer by linking to _DllUnregisterServer@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _DllRegisterServer by linking to _DllRegisterServer@0 Regards, Hiroshi Saito