Thread: ecpg tests make failed on Win32/MinGW

ecpg tests make failed on Win32/MinGW

From

"William ZHANG"

Date:

10 August 2006, 15:05:01

I tested it on the CVS head source.

C:\> ver

Microsoft Windows XP [Version 5.1.2600]

$ uname -a
MINGW32_NT-5.1 BEAR 1.0.11(0.46/3/2) 2004-04-30 18:55 i686 unknown

$ pwd
/home/uniware/pgsql/src/interfaces/ecpg/test/sql

$ make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-
statement -Wendif-labels -fno-strict-aliasing -g  -I./../../include -I../../../.
./../src/interfaces/libpq -I../../include -I../../../../../src/include -L../../.
./../../src/port -Wl,--allow-multiple-definition   -L../../ecpglib -L../../pgtyp
eslib -L../../../libpq 
func.c -lpgport  -lws2_32 -lshfolder -lpgtypes -lecpg -lp
q  -o func
func.pgc: In function `main':
func.pgc:18: error: missing terminating " character
func.pgc:22: error: `BEGIN' undeclared (first use in this function)
func.pgc:22: error: (Each undeclared identifier is reported only once
func.pgc:22: error: for each function it appears in.)
func.pgc:22: error: syntax error before "RAISE"
func.pgc:22:16: warning: character constant too long for its type
func.pgc:24: error: `RETURN' undeclared (first use in this function)
func.pgc:26: error: `END' undeclared (first use in this function)
func.pgc:26: error: `$test$' undeclared (first use in this function)
func.pgc:26: error: syntax error before "language"
func.pgc:26: error: missing terminating " character
make: *** [func] Error 1

A quick look at C file func.c found that:
    49 #line 16 "func.pgc"    50 ^M    51 ^M    52   { ECPGdo(__LINE__, 0, 1, NULL, "create  function My_Table_Check ()

ret
urns trigger  as $test$^M\    53     BEGIN^M\    54     RAISE WARNING 'Notice: TG_NAME=%, TG WHEN=%', TG_NAME, 
TG_WHEN;^M\    55     RETURN NEW;^M\    56     END; $test$ language plpgsql", ECPGt_EOIT, ECPGt_EORT);    57 #line 24
"func.pgc"   58    59 if (sqlca.sqlwarn[0] == 'W') sqlprint();    60 #line 24 "func.pgc"    61    62 if (sqlca.sqlcode
<0) sqlprint();}    63 #line 24 "func.pgc"
 

There are "^M"s followed by "\". It seems that the "^M"s are generated by 
the lexer/grammer.
Any one knows the actual cause?

-- 
With regards,
William ZHANG

Re: ecpg tests make failed on Win32/MinGW

From

Andrew Dunstan

Date:

10 August 2006, 15:13:47

Something must be odd in your environment - we have several Windows 
buildfarm members running through on CVS HEAD quite happily.

cheers

andrew

William ZHANG wrote:
> I tested it on the CVS head source.
>
> C:\> ver
>
> Microsoft Windows XP [Version 5.1.2600]
>
> $ uname -a
> MINGW32_NT-5.1 BEAR 1.0.11(0.46/3/2) 2004-04-30 18:55 i686 unknown
>
> $ pwd
> /home/uniware/pgsql/src/interfaces/ecpg/test/sql
>
> $ make
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-
> statement -Wendif-labels -fno-strict-aliasing -g  -I./../../include -I../../../.
> ./../src/interfaces/libpq -I../../include -I../../../../../src/include -L../../.
> ./../../src/port -Wl,--allow-multiple-definition   -L../../ecpglib -L../../pgtyp
> eslib -L../../../libpq 
> func.c -lpgport  -lws2_32 -lshfolder -lpgtypes -lecpg -lp
> q  -o func
> func.pgc: In function `main':
> func.pgc:18: error: missing terminating " character
> func.pgc:22: error: `BEGIN' undeclared (first use in this function)
> func.pgc:22: error: (Each undeclared identifier is reported only once
> func.pgc:22: error: for each function it appears in.)
> func.pgc:22: error: syntax error before "RAISE"
> func.pgc:22:16: warning: character constant too long for its type
> func.pgc:24: error: `RETURN' undeclared (first use in this function)
> func.pgc:26: error: `END' undeclared (first use in this function)
> func.pgc:26: error: `$test$' undeclared (first use in this function)
> func.pgc:26: error: syntax error before "language"
> func.pgc:26: error: missing terminating " character
> make: *** [func] Error 1
>
> A quick look at C file func.c found that:
>
>      49 #line 16 "func.pgc"
>      50 ^M
>      51 ^M
>      52   { ECPGdo(__LINE__, 0, 1, NULL, "create  function My_Table_Check () 
> ret
> urns trigger  as $test$^M\
>      53     BEGIN^M\
>      54     RAISE WARNING 'Notice: TG_NAME=%, TG WHEN=%', TG_NAME, 
> TG_WHEN;^M\
>      55     RETURN NEW;^M\
>      56     END; $test$ language plpgsql", ECPGt_EOIT, ECPGt_EORT);
>      57 #line 24 "func.pgc"
>      58
>      59 if (sqlca.sqlwarn[0] == 'W') sqlprint();
>      60 #line 24 "func.pgc"
>      61
>      62 if (sqlca.sqlcode < 0) sqlprint();}
>      63 #line 24 "func.pgc"
>
> There are "^M"s followed by "\". It seems that the "^M"s are generated by 
> the lexer/grammer.
> Any one knows the actual cause?
>
>

Re: ecpg tests make failed on Win32/MinGW

From

"William ZHANG"

Date:

11 August 2006, 16:11:41

I have found the cause.

The source file func.pgc is in DOS format, using CRLF(\r\n, or 0x0D0A) as
the newline character(s). That's why I got the output:

$ make func.o
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-
statement -Wendif-labels -fno-strict-aliasing -g  -I./../../include -I../../../.
./../src/interfaces/libpq -I../../include -I../../../../../src/include -I./../..
/include -I../../../../../src/interfaces/libpq -I../../../../../src/include
-I./src/include/port/win32 -DEXEC_BACKEND 
"-I../../../../../src/include/port/win32"  -c -o func.o func.c -MMD -MP -MF .deps/func.Po
func.pgc: In function `main':
func.pgc:18: error: missing terminating " character
func.pgc:22: error: `BEGIN' undeclared (first use in this function)
func.pgc:22: error: (Each undeclared identifier is reported only once
func.pgc:22: error: for each function it appears in.)
func.pgc:22: error: syntax error before "RAISE"
func.pgc:22:16: warning: character constant too long for its type
func.pgc:24: error: `RETURN' undeclared (first use in this function)
func.pgc:26: error: `END' undeclared (first use in this function)
func.pgc:26: error: `$test$' undeclared (first use in this function)
func.pgc:26: error: syntax error before "language"
func.pgc:26: error: missing terminating " character
make: *** [func.o] Error 1

Now I change the file to use UNIX format, using LF(\n, or 0x0A) as the
newline character. Everything is OK then:

$ make func.o
../../preproc/ecpg -I./../../include -o func.c -I. func.pgc
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-
statement -Wendif-labels -fno-strict-aliasing -g  -I./../../include -I../../../.
./../src/interfaces/libpq -I../../include -I../../../../../src/include -I./../..
/include -I../../../../../src/interfaces/libpq -I../../../../../src/include
-I./src/include/port/win32 -DEXEC_BACKEND 
"-I../../../../../src/include/port/win32"  -c -o func.o func.c -MMD -MP -MF .deps/func.Po

Most of the time, the lexer will recognize differnt kinds of newline
characters in the pgc file (see comments in file pgc.l at about line 237).
But for lines in dollar quoted strings, it will preserve the newline 
characters.
And in output_escaped_str() from preproc/output.c, we will replace  '\n' 
with
'\' and '\n'. Since the input string ends with "\r\n", after the replace, it
becomes '\r', '\', '\n'. That's why I have seen "^M\" in func.c.

Some lines of output from func.c(func.pgc in DOS format, showed in vim):

#line 16 "func.pgc"
^M
^M { ECPGdo(__LINE__, 0, 1, NULL, "create  function My_Table_Check () returns
trigger  as $test$^M\   BEGIN^M\   RAISE WARNING 'Notice: TG_NAME=%, TG WHEN=%', TG_NAME, TG_WHEN;^M\   RETURN NEW;^M\
END; $test$ language plpgsql", ECPGt_EOIT, ECPGt_EORT);
 
#line 24 "func.pgc"

if (sqlca.sqlwarn[0] == 'W') sqlprint();
#line 24 "func.pgc"

if (sqlca.sqlcode < 0) sqlprint();}
#line 24 "func.pgc"
^M
^M

Lines of output from func.c(func.pgc in UNIX format):

#line 16 "func.pgc"

 { ECPGdo(__LINE__, 0, 1, NULL, "create  function My_Table_Check () returns
trigger  as $test$\   BEGIN\   RAISE WARNING 'Notice: TG_NAME=%, TG WHEN=%', TG_NAME, TG_WHEN;\   RETURN NEW;\   END;
$test$language plpgsql", ECPGt_EOIT, ECPGt_EORT);
 
#line 24 "func.pgc"

if (sqlca.sqlwarn[0] == 'W') sqlprint();
#line 24 "func.pgc"

if (sqlca.sqlcode < 0) sqlprint();}
#line 24 "func.pgc"

Should we modify output_escaped_str() to work around this problem?

-- 
With regards,
William ZHANG

Re: ecpg tests make failed on Win32/MinGW

From

Michael Meskes

Date:

15 August 2006, 06:15:50

On Sat, Aug 12, 2006 at 12:11:21AM +0800, William ZHANG wrote:
> I have found the cause.
> ...

Thanks a lot for your effort.

In a few minutes I will commit a change that fixed this in my tests
(don't worry about the timestamp of this email, I'm writing while
sitting in a train).

All it does is check for "\r\n" and escape it as one character, i.e.
print "\\\r\n". Please test this is thoroughly as possible. I do not
have a Windows machine to test on, but on my Linux box all
regression tests run successfully no matter which encoding the *.pgc
files have.

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!

Re: ecpg tests make failed on Win32/MinGW

From

"William ZHANG"

Date:

15 August 2006, 14:58:02

"Michael Meskes" <meskes@postgresql.org>
> On Sat, Aug 12, 2006 at 12:11:21AM +0800, William ZHANG wrote:
>> I have found the cause.
>> ...
>
> Thanks a lot for your effort.
   You are welcome.

> In a few minutes I will commit a change that fixed this in my tests
> (don't worry about the timestamp of this email, I'm writing while
> sitting in a train).
>
> All it does is check for "\r\n" and escape it as one character, i.e.
> print "\\\r\n". Please test this is thoroughly as possible. I do not
> have a Windows machine to test on, but on my Linux box all
> regression tests run successfully no matter which encoding the *.pgc
> files have.

I have download the lastest CVS HEAD and make clean, make check.
Everything is OK. I have also tried it on func.pgc both in DOS and UNIX
format. Thank you!

But Mac OS use CR('\r') as the newline character, and if I convert func.pgc
to use CR. "make func.o" failed on MSYS/MinGW.  But I have no Mac OS
to test on it.

I think we should support the following:

1. DOS, source file in CRLF format
2. UNIX, source file in LF format
3. Mac OS, source file in CR format

If the OS and the file format does not match, we may expect errors.
Actually, we now support both CRLF and LF on Win32 and Linux.
(from your tests and mine.)

-- 
With regards,
William ZHANG