Bug 109

Summary: Compilation fails on Mac Snow Leopard
Product: Slony-I Reporter: Peter Smith <lerxst97>
Component: slony_logshipperAssignee: Slony Bugs List <slony1-bugs>
Status: RESOLVED WONTFIX    
Severity: minor CC: slony1-bugs
Priority: low    
Version: devel   
Hardware: Macintosh   
OS: Mac OS   

Description Peter Smith 2010-01-04 13:49:05 PST
Hi,

Building Slony 2.0.2 or 2.0.3rc3 against PostgreSQL 8.4.2 on Snow Leopard fails
while compiling src/slony_logshipper/parser.c ...

gcc -g -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../..
-DPGSHARE="\"/opt/local/share/postgresql84/\"" 
-I/opt/local/include/postgresql84/ -I/opt/local/include/postgresql84/server/  
-c -o parser.o parser.c
In file included from parser.y:1101:
scan.c:161: error: conflicting types for 'yyleng'
parser.y:25: error: previous declaration of 'yyleng' was here
scan.c:288: error: conflicting types for 'yyleng'
parser.y:25: error: previous declaration of 'yyleng' was here

The OS is 10.6.2 and hardware is a 2009 Mac mini.  "uname -a" returns this
signature...

Darwin pratt 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov  3 10:37:10 PST 2009;
root:xnu-1486.2.11~1/RELEASE_I386 i386

The same bug manifests under 10.6.2 on a 2005 MacBook.

This patch to src/slony_logshipper/scan.c applied *after* it's generated allows
the compilation to finish.  This is obviously a hack and I don't know yacc well
enough to fix it properly.


--- scan.c.virgin    2010-01-04 13:44:10.000000000 -0800
+++ scan.c    2010-01-04 13:44:40.000000000 -0800
@@ -158,7 +158,7 @@
 typedef size_t yy_size_t;
 #endif

-extern yy_size_t yyleng;
+extern int yyleng;

 extern FILE *yyin, *yyout;

@@ -285,7 +285,7 @@
 /* yy_hold_char holds the character lost when yytext is formed. */
 static char yy_hold_char;
 static yy_size_t yy_n_chars;        /* number of characters read into
yy_ch_buf */
-yy_size_t yyleng;
+int yyleng;

 /* Points to current character in buffer. */
 static char *yy_c_buf_p = (char *) 0;
Comment 1 Christopher Browne 2010-02-11 09:52:50 PST
Both parser.c and scan.c are generated files, so it seems inapropos to resolve
the conflict by editing the code.

The very same problem came up on the build farm, and was discussed on
pgsql-general and -hackers:

http://archives.postgresql.org/pgsql-general/2009-09/msg00259.php
http://archives.postgresql.org/pgsql-hackers/2009-09/msg00313.php

It looks as though Apple has hacked their version of flex to do something
wacky.

Here was the "solution" part, as near as I can tell...

http://archives.postgresql.org/pgsql-hackers/2009-09/msg00326.php

Unfortunately, the change that Tom Lane implemented at that time doesn't seem
applicable here.

My suggestion is to use a flex/bison combination that matches better.

I have added docs on this to the FAQ for 2.0 + HEAD.