Not *quite* there on ecpg fixes

Started by Tom Laneover 18 years ago15 messages
#1Tom Lane
tgl@sss.pgh.pa.us

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

#2Michael Meskes
meskes@postgresql.org
In reply to: Tom Lane (#1)
Re: 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: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

#3Andrew Dunstan
andrew@dunslane.net
In reply to: Michael Meskes (#2)
Re: 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

#4Alvaro Herrera
alvherre@commandprompt.com
In reply to: Andrew Dunstan (#3)
Re: 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)

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andrew Dunstan (#3)
Re: Not *quite* there on ecpg fixes

Andrew Dunstan <andrew@dunslane.net> 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

#6Michael Meskes
meskes@postgresql.org
In reply to: Alvaro Herrera (#4)
Re: 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: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

#7Alvaro Herrera
alvherre@commandprompt.com
In reply to: Michael Meskes (#6)
Re: 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 Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

#8Tom Lane
tgl@sss.pgh.pa.us
In reply to: Alvaro Herrera (#7)
Re: Not *quite* there on ecpg fixes

Alvaro Herrera <alvherre@commandprompt.com> 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

#9Alvaro Herrera
alvherre@commandprompt.com
In reply to: Michael Meskes (#6)
Re: 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 Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

#10Kris Jurka
books@ejurka.com
In reply to: Tom Lane (#5)
Re: Not *quite* there on ecpg fixes

On Thu, 4 Oct 2007, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> 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

#11Andrew Dunstan
andrew@dunslane.net
In reply to: Michael Meskes (#6)
Re: 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

#12Michael Meskes
meskes@postgresql.org
In reply to: Alvaro Herrera (#9)
Re: 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: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

#13Tom Lane
tgl@sss.pgh.pa.us
In reply to: Michael Meskes (#12)
Re: Not *quite* there on ecpg fixes

Michael Meskes <meskes@postgresql.org> 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

#14Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andrew Dunstan (#11)
Re: Not *quite* there on ecpg fixes

Andrew Dunstan <andrew@dunslane.net> 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

#15Michael Meskes
meskes@postgresql.org
In reply to: Tom Lane (#13)
Re: 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: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!