MySQL Bugs: #24619: "make distcheck" fails when building the sql

Bug #24619	"make distcheck" fails when building the sql_yacc.o target
Submitted:	27 Nov 2006 12:23	Modified:	27 Nov 2006 13:55
Reporter:	Lenz Grimmer	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: Compiling	Severity:	S3 (Non-critical)
Version:	5.0.32-BK, 5.0-current	OS:	Linux (Linux)
Assigned to:		CPU Architecture:	Any

Description:
"BUILD/compile-dist ; make distcheck" in the 5.0 tree currently fails with the following error:

5.0.32-nightly-20061127-build/build/mysql-5.0.32-nightly-20061127/_inst/var\"" -DSHAREDIR="\"/data0/
autobuild/autobuild/mysql-5.0.32-nightly-20061127-build/build/mysql-5.0.32-nightly-20061127/_inst/sh
are/mysql\"" -DHAVE_CONFIG_H -I. -I../../sql -I.. -I../innobase/include -I../include -I../../include
 -I../../regex -I../../sql     -O3 -DDBUG_OFF    -fno-implicit-templates -fno-exceptions -fno-rtti -
MT sql_parse.o -MD -MP -MF ".deps/sql_parse.Tpo" -c -o sql_parse.o ../../sql/sql_parse.cc; \
then mv -f ".deps/sql_parse.Tpo" ".deps/sql_parse.Po"; else rm -f ".deps/sql_parse.Tpo"; exit 1; fi
/bin/sed -e 's/__attribute__ ((__unused__))//' sql_yacc.cc > sql_yacc.cc-new
/bin/sed: can't read sql_yacc.cc: No such file or directory

This was caused by Monty's last changes to sql/Makefile.am:

sql/Makefile.am 1.127 2006/11/20 22:41:50 monty@mysql.com
  Fix for bison 1.875, which adds an attribute statement that gcc 4.1.0 can't parse

The offending code:

sql_yacc.o:	sql_yacc.cc sql_yacc.h $(HEADERS)
		@SED@ -e 's/__attribute__ ((__unused__))//' sql_yacc.cc > sql_yacc.cc-new
		@MV@ sql_yacc.cc-new sql_yacc.cc

How to repeat:
Get a current 5.0 clone, run "BUILD/compile-dist ; make distcheck", observe the error.

Suggested fix:
Make sure to add the appropriate $(top_srcdir) and $(top_builddir) variables to the file names used in the sed/mv calls.

This is very likely a duplicate of Bug #24557 - I just wanted to provide some more details.

Verified just as described with latest 5.0.32-BK on Linux. Let's consider it a duplicate of bug #24557.

if the goal is to get rid of attributes, I'd rather define __attribute__ to the empty macro, instead of sed hacks. But first I'd try to understand why bison is doing it

GCC 4 not understanding __attribute__ seems wrong.
Instead, this root cause could be related to Bug#2717,
which has been there forever, but fixed really recently.

Note that with bison 2.2, the generated code does not contain
any __attribute__ anyway (did not checked with bison 1.875).

Even with bison 1.875, I would be surprised that the generated code
does not build on all platforms with all compilers,
so the root cause is elsewhere, and the sed hack is not the correct fix.