Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
Robert Creager wrote: Upgraded to Snow Leopard Saturday, and am having problems building now. The build logs are here http://buildfarm.postgresql.org/cgi-bin/show_status.pl?member=polecat And the failing part is here: make -C preproc all make -C ../../../../src/port all make[5]: Nothing to be done for `all'. /usr/bin/perl ./parse.pl . ../../../backend/parser/gram.y preproc.y /usr/bin/bison -d -o preproc.c preproc.y /usr/bin/flex -o'pgc.c' pgc.l /opt/local/bin/ccache gcc -no-cpp-precomp -I/opt/local/include -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -DECPG_COMPILE -I../include -I../../../../src/interfaces/ecpg/include -I. -I. -DMAJOR_VERSION=4 -DMINOR_VERSION=6 -DPATCHLEVEL=0 -I../../../../src/include -I/usr/include/libxml2 -c -o preproc.o preproc.c In file included from preproc.y:12065: pgc.c:161: error: conflicting types for 'yyleng' extern.h:43: error: previous declaration of 'yyleng' was here pgc.c:288: error: conflicting types for 'yyleng' extern.h:43: error: previous declaration of 'yyleng' was here make[4]: *** [preproc.o] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 Please try building by hand and examine the files to find out what the conflict is between these declarations. This is really a -hackers question. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 11:29 AM, Andrew Dunstan wrote: Robert Creager wrote: Upgraded to Snow Leopard Saturday, and am having problems building now. The build logs are here http://buildfarm.postgresql.org/cgi-bin/show_status.pl?member=polecat And the failing part is here: make -C preproc all make -C ../../../../src/port all make[5]: Nothing to be done for `all'. /usr/bin/perl ./parse.pl . ../../../backend/parser/gram.y preproc.y /usr/bin/bison -d -o preproc.c preproc.y /usr/bin/flex -o'pgc.c' pgc.l /opt/local/bin/ccache gcc -no-cpp-precomp -I/opt/local/include - Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after- statement -Wendif-labels -fno-strict-aliasing -fwrapv -g - DECPG_COMPILE -I../include -I../../../../src/interfaces/ecpg/ include -I. -I. -DMAJOR_VERSION=4 -DMINOR_VERSION=6 -DPATCHLEVEL=0 - I../../../../src/include -I/usr/include/libxml2 -c -o preproc.o preproc.c In file included from preproc.y:12065: pgc.c:161: error: conflicting types for 'yyleng' extern.h:43: error: previous declaration of 'yyleng' was here pgc.c:288: error: conflicting types for 'yyleng' extern.h:43: error: previous declaration of 'yyleng' was here make[4]: *** [preproc.o] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 Please try building by hand and examine the files to find out what the conflict is between these declarations. This is really a -hackers question. pgc.c - 161: extern yy_size_t yyleng; extern.h - 43 : extern int yylineno, yyleng; Thanks, Rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
Robert Creager rob...@logicalchaos.org writes: On Sep 7, 2009, at 11:29 AM, Andrew Dunstan wrote: Please try building by hand and examine the files to find out what the conflict is between these declarations. pgc.c - 161: extern yy_size_t yyleng; Bizarre --- my copy of flex 2.5.35 definitely puts out int, and so does everybody else's. Did Apple take it on their own head to change this? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 1:18 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Creager rob...@logicalchaos.org writes: On Sep 7, 2009, at 11:29 AM, Andrew Dunstan wrote: Please try building by hand and examine the files to find out what the conflict is between these declarations. pgc.c - 161: extern yy_size_t yyleng; Bizarre --- my copy of flex 2.5.35 definitely puts out int, and so does everybody else's. Did Apple take it on their own head to change this? regards, tom lane I'll try the macports version, and see what happens. Cheers, Rob Sent from my iPhone -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On 9/7/09, Robert Creager rob...@logicalchaos.org wrote: On Sep 7, 2009, at 1:18 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Creager rob...@logicalchaos.org writes: On Sep 7, 2009, at 11:29 AM, Andrew Dunstan wrote: Please try building by hand and examine the files to find out what the conflict is between these declarations. pgc.c - 161: extern yy_size_t yyleng; Bizarre --- my copy of flex 2.5.35 definitely puts out int, and so does everybody else's. Did Apple take it on their own head to change this? regards, tom lane I'll try the macports version, and see what happens. FYI, I've been building from source on Snow Leopard without any problems. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 1:18 PM, Tom Lane wrote: Robert Creager rob...@logicalchaos.org writes: On Sep 7, 2009, at 11:29 AM, Andrew Dunstan wrote: Please try building by hand and examine the files to find out what the conflict is between these declarations. pgc.c - 161: extern yy_size_t yyleng; Bizarre --- my copy of flex 2.5.35 definitely puts out int, and so does everybody else's. Did Apple take it on their own head to change this? Apparently so - the /opt version is from macports. It works. % /opt/local/bin/flex --version flex 2.5.35 % /usr/bin/flex --version flex 2.5.35 Next problems, with HEAD and 8_4, 8_3, 8_2, are here - all with the same error: http://buildfarm.postgresql.org/cgi-bin/show_status.pl?member=polecat ... == running regression test queries== test tablespace ... FAILED ... == pgsql.41144/src/test/regress/regression.diffs === *** /usr/local/src/build-farm-3.2/builds/HEAD/pgsql.41144/src/test/ regress/expected/tablespace.out Mon Sep 7 14:03:30 2009 --- /usr/local/src/build-farm-3.2/builds/HEAD/pgsql.41144/src/test/ regress/results/tablespace.out Mon Sep 7 14:03:43 2009 *** *** 73,75 --- 73,76 drop cascades to table testschema.atable -- Should succeed DROP TABLESPACE testspace; + ERROR: could not read directory pg_tblspc/16388: Invalid argument Sigh, Rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 2:17 PM, Dave Page wrote: FYI, I've been building from source on Snow Leopard without any problems. If your building from the official tarball, bison/flex are not used. I'm building from CVS, where bison/flex are used. Cheers, rob -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On 9/7/09, Robert Creager rob...@logicalchaos.org wrote: On Sep 7, 2009, at 2:17 PM, Dave Page wrote: FYI, I've been building from source on Snow Leopard without any problems. If your building from the official tarball, bison/flex are not used. I'm building from CVS, where bison/flex are used. Building from CVS, but on closer examination I do have Macports versions of bison/flex ahead of Apple's in the path. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
Robert Creager rob...@logicalchaos.org writes: On Sep 7, 2009, at 1:18 PM, Tom Lane wrote: Robert Creager rob...@logicalchaos.org writes: extern yy_size_t yyleng; Bizarre --- my copy of flex 2.5.35 definitely puts out int, and so does everybody else's. Did Apple take it on their own head to change this? Apparently so - the /opt version is from macports. It works. [ Well, I knew I was going to be buying a copy of Snow Leopard sometime soon. One trip to the Apple store later ... ] Yeah, I've confirmed this. It appears that Apple has absorbed this as-yet-unreleased upstream patch into their 2.5.35 version: http://flex.cvs.sourceforge.net/viewvc/flex/flex/flex.skl?r1=2.212r2=2.213 This is probably not the brightest thing the flex developers have ever done, as there is now absolutely no way to predict the type of yyleng externally to the generated scan.c file. They might as well not export it at all. However, I think we can work around it. AFAICS, the only reason ecpg has an extern for yyleng is because preproc.y's make_name() uses it, and there doesn't seem to be any compelling reason why that function shouldn't just do mm_strdup(yytext) instead. I don't see any other places where we are referring to yyleng outside of a scanner file. (Alternatively, make_name() could be moved into pgc.l, but I doubt it's worth the work to avoid one extra strlen calculation.) Presumably, versions of flex containing this change will start to show up at other places besides Apple sometime soon. So I'm thinking we need to back-patch the fix to whatever branches we think are likely to get compiled from CVS on newer platforms. Any feelings about that? Should I just hit everything back to 7.4 to be safe? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 2:41 PM, Dave Page dp...@pgadmin.org wrote: On 9/7/09, Robert Creager rob...@logicalchaos.org wrote: On Sep 7, 2009, at 2:17 PM, Dave Page wrote: FYI, I've been building from source on Snow Leopard without any problems. If your building from the official tarball, bison/flex are not used. I'm building from CVS, where bison/flex are used. Building from CVS, but on closer examination I do have Macports versions of bison/flex ahead of Apple's in the path. Does your make config work? Are you using the 32 or 64 bit kernel? Cheers, Rob Sent from my iPhone -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 4:08 PM, Tom Lane t...@sss.pgh.pa.us wrote: Any feelings about that? Should I just hit everything back to 7.4 to be safe? I've noticed on 7.4, Mac gets a spinlock compile error (see polecat logs on buildfarm). Should I give up on the mac for 7.4? Cheers, Rob Sent from my iPhone -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
Robert Creager rob...@logicalchaos.org writes: Next problems, with HEAD and 8_4, 8_3, 8_2, are here - all with the same error: -- Should succeed DROP TABLESPACE testspace; + ERROR: could not read directory pg_tblspc/16388: Invalid argument Yeah, this is a known Snow Leopard bug --- see last month's report from Jan Otto. I think our plan is to wait and see if Apple fixes it in 10.6.1 before we consider whether it's worth installing a kluge workaround. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
Robert Creager rob...@logicalchaos.org writes: I've noticed on 7.4, Mac gets a spinlock compile error (see polecat logs on buildfarm). Should I give up on the mac for 7.4? 7.4 thinks that Darwin only runs on PPC. We are not going to fix it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
I wrote: Yeah, I've confirmed this. It appears that Apple has absorbed this as-yet-unreleased upstream patch into their 2.5.35 version: http://flex.cvs.sourceforge.net/viewvc/flex/flex/flex.skl?r1=2.212r2=2.213 ... However, I think we can work around it. AFAICS, the only reason ecpg has an extern for yyleng is because preproc.y's make_name() uses it, and there doesn't seem to be any compelling reason why that function shouldn't just do mm_strdup(yytext) instead. I've committed patches for this --- it should be safe to go back to using OS X's native flex on your buildfarm machine. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
