Re: [HACKERS] Not *quite* there on ecpg fixes
On Thu, Oct 04, 2007 at 02:12:14PM -0400, Tom Lane wrote: I see that libpq manufactures three different .def files, whereas the ecpg code is only making two. Is this OK or an oversight? I'm not Not knowing what the third one is for I deliberately created only two. If there is a reason for the 3rd I'lö surely add it. clear on the reason for the two different MSVC .def files in libpq. Also, do we actually care about supporting Borland builds of ecpg --- maybe we don't need the 'b' versions for ecpg? Fine with me. Do we need it in libpq? Or else we could remove if everywhere. Maybe someone's working on it. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Not *quite* there on ecpg fixes
On Thu, Oct 04, 2007 at 12:47:13AM -0400, Tom Lane wrote: Buildfarm member brown_bat (cygwin/gcc) still isn't happy: ... Just committed a patch that hopefully solves this. Kind of surprises me that this only occurs on cygwin. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Not *quite* there on ecpg fixes
Michael Meskes wrote: On Thu, Oct 04, 2007 at 12:47:13AM -0400, Tom Lane wrote: Buildfarm member brown_bat (cygwin/gcc) still isn't happy: ... Just committed a patch that hopefully solves this. Kind of surprises me that this only occurs on cygwin. It's still not working. Don't have time right now to diagnose why. For now, since Michael doesn't have a windows machine to play with, I have switched brown_bat's schedule so it runs HEAD 6 times a day (not exactly every 4 hours, the intervals vary between 3 and 4 1/2 hours). cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Not *quite* there on ecpg fixes
Andrew Dunstan wrote: Michael Meskes wrote: On Thu, Oct 04, 2007 at 12:47:13AM -0400, Tom Lane wrote: Buildfarm member brown_bat (cygwin/gcc) still isn't happy: ... Just committed a patch that hopefully solves this. Kind of surprises me that this only occurs on cygwin. It's still not working. It looks like dlltool does not like the .def file: dllwrap -Wl,--enable-auto-import -o cygpgtypes.dll --dllname cygpgtypes.dll --def libpgtypesdll.def numeric.o datetime.o common.o dt_common.o timestamp.o interval.o pgstrcasecmp.o -L../../../../src/port -L/usr/local/lib -lm dlltool: Syntax error in def file libpgtypesdll.def:3 dlltool: Syntax error in def file libpgtypesdll.def:3 dlltool --dllname cygpgtypes.dll --def libpgtypesdll.def --output-lib libpgtypes.a dlltool: Syntax error in def file libpgtypesdll.def:3 Line 3 of that file is unadorned EXPORTS: echo '; DEF file for MS VC++' libpgtypesdll.def echo 'LIBRARY LIBPGTYPES' libpgtypesdll.def echo 'EXPORTS' libpgtypesdll.def The error that actually finishes the build is below: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -I../include -I../../../../src/interfaces/ecpg/include -I../../../../src/interfaces/libpq -I../../../../src/port -I../../../../src/include -DBUILDING_DLL -c -o thread.o thread.c dllwrap -Wl,--enable-auto-import -o cygecpg.dll --dllname cygecpg.dll --def libecpgdll.def execute.o typename.o descriptor.o data.o error.o prepare.o memory.o connect.o misc.o path.o thread.o -L../pgtypeslib -L../../../../src/interfaces/libpq -L../../../../src/port -L/usr/local/lib -lpgtypes -lpq -lm execute.o: In function `ecpg_store_input': /home/AndrewDunstan/bf/root/HEAD/pgsql.2768/src/interfaces/ecpg/ecpglib/execute.c:979: undefined reference to `_PGTYPEStimestamp_to_asc' [...] I wonder why the dlltool failure is not causing the build to fail immediately? -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC The Postgresql hackers have what I call a NASA space shot mentality. Quite refreshing in a world of weekend drag racer developers. (Scott Marlowe) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Not *quite* there on ecpg fixes
Andrew Dunstan [EMAIL PROTECTED] writes: It's still not working. Don't have time right now to diagnose why. For now, since Michael doesn't have a windows machine to play with, I have switched brown_bat's schedule so it runs HEAD 6 times a day (not exactly every 4 hours, the intervals vary between 3 and 4 1/2 hours). I wonder if we could get trout back in the rotation, too? regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Not *quite* there on ecpg fixes
On Thu, Oct 04, 2007 at 10:04:41AM -0400, Alvaro Herrera wrote: It looks like dlltool does not like the .def file: ... Line 3 of that file is unadorned EXPORTS: echo '; DEF file for MS VC++' libpgtypesdll.def echo 'LIBRARY LIBPGTYPES' libpgtypesdll.def echo 'EXPORTS' libpgtypesdll.def ... I wonder why the dlltool failure is not causing the build to fail immediately? These lines are simply copied from libpq/Makefile but ddltool does not complain while working on libpq. Any idea where they differ? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Not *quite* there on ecpg fixes
Michael Meskes wrote: On Thu, Oct 04, 2007 at 10:04:41AM -0400, Alvaro Herrera wrote: It looks like dlltool does not like the .def file: ... Line 3 of that file is unadorned EXPORTS: echo '; DEF file for MS VC++' libpgtypesdll.def echo 'LIBRARY LIBPGTYPES' libpgtypesdll.def echo 'EXPORTS' libpgtypesdll.def ... I wonder why the dlltool failure is not causing the build to fail immediately? These lines are simply copied from libpq/Makefile but ddltool does not complain while working on libpq. Any idea where they differ? Newline style perhaps? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Not *quite* there on ecpg fixes
Alvaro Herrera [EMAIL PROTECTED] writes: Michael Meskes wrote: These lines are simply copied from libpq/Makefile but ddltool does not complain while working on libpq. Any idea where they differ? Newline style perhaps? There seems to be a blank line at the end of interfaces/ecpg/pgtypeslib/exports.txt ... maybe that is producing a bogus line in the .def file? regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Not *quite* there on ecpg fixes
Michael Meskes wrote: On Thu, Oct 04, 2007 at 10:04:41AM -0400, Alvaro Herrera wrote: It looks like dlltool does not like the .def file: ... Line 3 of that file is unadorned EXPORTS: echo '; DEF file for MS VC++' libpgtypesdll.def echo 'LIBRARY LIBPGTYPES' libpgtypesdll.def echo 'EXPORTS' libpgtypesdll.def ... I wonder why the dlltool failure is not causing the build to fail immediately? These lines are simply copied from libpq/Makefile but ddltool does not complain while working on libpq. Any idea where they differ? The libpq exports.txt has spaces, not tabs, as separators. In fact, if you see the .def files you notice that the generated files for ecpg are all wrong. Simplest is to change tabs to spaces ... However I'm thinking that maybe it's better to change the sed line to consider both spaces and tabs in the regex. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Not *quite* there on ecpg fixes
On Thu, 4 Oct 2007, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: It's still not working. Don't have time right now to diagnose why. For now, since Michael doesn't have a windows machine to play with, I have switched brown_bat's schedule so it runs HEAD 6 times a day (not exactly every 4 hours, the intervals vary between 3 and 4 1/2 hours). I wonder if we could get trout back in the rotation, too? Both trout and eel are permanently dead due to a drive failure. I can potentially setup new animals next week, but these are gone. Kris Jurka ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Not *quite* there on ecpg fixes
Michael Meskes wrote: On Thu, Oct 04, 2007 at 10:04:41AM -0400, Alvaro Herrera wrote: It looks like dlltool does not like the .def file: ... Line 3 of that file is unadorned EXPORTS: echo '; DEF file for MS VC++' libpgtypesdll.def echo 'LIBRARY LIBPGTYPES' libpgtypesdll.def echo 'EXPORTS' libpgtypesdll.def ... I wonder why the dlltool failure is not causing the build to fail immediately? These lines are simply copied from libpq/Makefile but ddltool does not complain while working on libpq. Any idea where they differ? One thing I noticed is this: ifneq ($(PORTNAME), win32) OBJS += thread.o DLL_DEFFILE=libecpgdll.def endif Why are we defining DLL_DEFFILE for the non-win32 case but not for the win32 case? That seems rather odd. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Not *quite* there on ecpg fixes
On Thu, Oct 04, 2007 at 12:35:29PM -0400, Alvaro Herrera wrote: The libpq exports.txt has spaces, not tabs, as separators. In fact, if you see the .def files you notice that the generated files for ecpg are all wrong. Right, that's it. Simplest is to change tabs to spaces ... However I'm thinking that maybe it's better to change the sed line to consider both spaces and tabs in the regex. I'm not sure how portable sed scripts containing tabs are, so I simply replaced the tabs in those export files by white spaces. Hopefully that'll do it. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Not *quite* there on ecpg fixes
Michael Meskes [EMAIL PROTECTED] writes: On Thu, Oct 04, 2007 at 12:35:29PM -0400, Alvaro Herrera wrote: The libpq exports.txt has spaces, not tabs, as separators. In fact, if you see the .def files you notice that the generated files for ecpg are all wrong. Right, that's it. I see that libpq manufactures three different .def files, whereas the ecpg code is only making two. Is this OK or an oversight? I'm not clear on the reason for the two different MSVC .def files in libpq. Also, do we actually care about supporting Borland builds of ecpg --- maybe we don't need the 'b' versions for ecpg? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Not *quite* there on ecpg fixes
Andrew Dunstan [EMAIL PROTECTED] writes: One thing I noticed is this: ifneq ($(PORTNAME), win32) OBJS += thread.o DLL_DEFFILE=libecpgdll.def endif Why are we defining DLL_DEFFILE for the non-win32 case but not for the win32 case? Comparing to the libpq Makefile, this seems definitely backward --- presumably the result is that Makefile.shlib overwrites the deffile with an all-symbols deffile, eliminating the intended limitation on which symbols are exported. Will fix. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Not *quite* there on ecpg fixes
Buildfarm member brown_bat (cygwin/gcc) still isn't happy: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -I../include -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/interfaces/libpq -I../../../../src/include -c -o pgstrcasecmp.o pgstrcasecmp.c dllwrap -Wl,--enable-auto-import -o cygpgtypes.dll --dllname cygpgtypes.dll --def libpgtypesdll.def numeric.o datetime.o common.o dt_common.o timestamp.o interval.o pgstrcasecmp.o -L../../../../src/port -L/usr/local/lib -lm dlltool: Can't open def file: libpgtypesdll.def dllwrap: dlltool exited with status 1 regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
