MySQL Bugs: #2690: bison -y -d sql_yacc.yy && mv y.tab.c sq y.tab.c

Bug #2690	bison -y -d sql_yacc.yy && mv y.tab.c sq y.tab.c - No such file or directory
Submitted:	9 Feb 2004 8:49	Modified:	10 Feb 2004 4:10
Reporter:	Joerg Behrens	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Compiling	Severity:	S3 (Non-critical)
Version:	4.0.x	OS:	Other (IRIX64 6.5.22)
Assigned to:	Konstantin Osipov	CPU Architecture:	Any

Description:
This reports refers to http://bugs.mysql.com/bug.php?id=2214 where is already reported that when using the C99 compiler mode also errors occurs.

export CC=cc
export CFLAGS="-c99 -LANG:libc_in_namespace_std=OFF"
export CXXFLAGS="-O3 -mips4"
export CXX=CC

Its the bitkeeper 4.0 checkout from 9.02.2004 
[origin]:/usr2/MIPS/mysql-4.0 $ ./configure --without-bench --without-docs --without-innodb --prefix=/tmp/mysql; gmake -j4

gmake[2]: Entering directory `/usr2/MIPS/mysql-4.0/sql'
bison -y  -d sql_yacc.yy && mv y.tab.c sql_yacc.cc
conflicts:  94 shift/reduce, 4 reduce/reduce
y.tab.c - No such file or directory
gmake[2]: *** [sql_yacc.cc] Error 2
gmake[2]: Leaving directory `/usr2/MIPS/mysql-4.0/sql'

bison --version
bison (GNU Bison) 1.75

In annotation to the previous report and answer. It looks also that a prefix with the '-O' value is always added to the users CFLAGS settings. This confuses the mips cc compiler and spells out warnings like 
"cc WARNING:  -O conflicts with -O3; using latter value (-O3)"

How to repeat:
Just try to compile mysql 4.x sources with a recent mips pro compiler (7.41)

- I wasn't able to repeat your bug with bison (GNU Bison) 1.75.
What version of bison are you using? Probably you need to upgrade.
- you should use our build script (BUILD/compile-irix-mips64-mipspro), your FLAGS setup is 
wrong.
- we're aware of that warning (-O conflicts with -O3) you mentioned. 
  It's harmless, so please ignore it by now.

Oh, sorry, I've just noticed that your bison version is the same as mine :)
Nevertheless I had no problems compiling. Could you try our build script and see if it helps?

Thanx for the fast responce Konstantin. I didnt take notice for the new IRIX buildscript because in the pass there never where those kind of script :)

Here is the output...
[origin]:/usr2/MIPS/mysql-4.0 $ gmake distclean
[origin]:/usr2/MIPS/mysql-4.0 $ BUILD/compile-irix-mips64-mipspro
gmake[2]: Leaving directory `/usr2/MIPS/mysql-4.0/vio'
Making all in sql
gmake[2]: Entering directory `/usr2/MIPS/mysql-4.0/sql'
bison -y  -d sql_yacc.yy && mv y.tab.c sql_yacc.cc
conflicts:  94 shift/reduce, 4 reduce/reduce
y.tab.c - No such file or directory
gmake[2]: *** [sql_yacc.cc] Error 2
gmake[2]: Leaving directory `/usr2/MIPS/mysql-4.0/sql'

So same error.

I dont know what you mean with 'your' *FLAGS are wrong. I have striped them down to avoid problem. Normaly they contains some more options.

Here are some short comments to the buildscript

- the mips4 instruction set are supportet by r5000 cpus and above and have nothing todo with 64bit
- the 3 different ABI are called o32, n32 and 64
- gnu make isnt part of the IRIX OS and i cant believe the the standard make can handle the mysql build process´. Gnu make can easily installed from a proper tardist but than it depends on the PATH which 'make' is used. So its better when using 'g'make to avoid confusion
- by default it makes more sense to build a 32bit version instead 64bit

regards
Joerg

Err...
What I meant when said that your flags are not good:
- you should pass -LANG options to C++ compiler, not C compiler. 

Thank you for explaining what option -mips4 is doing. Could you send me a patch to the build script, including all your corrections?

Besides that I'm stuck - I'm still able to compile it on our SGI IRIX MIPSPro 7.41 box.
So I'd suspect the problem lies somewhere in your environment.
If you could give me ssh login to your box, it should simplify matters.

OK, I finally was able to repeat the bug.
Thank you for your feedback!

> Err...
> What I meant when said that your flags are not good:
> - you should pass -LANG options to C++ compiler, not C compiler. 

AHHHH... i'm blind.

> Thank you for explaining what option -mips4 is doing. Could you
> send me a patch
> to the build script, including all your corrections?

Yes. I'll add some infos to the comments and i change the ABI and Compiler Flags

> Besides that I'm stuck - I'm still able to compile it on
> our SGI IRIX MIPSPro 7.41 box.
> So I'd suspect the problem lies somewhere in your environment.
> If you could give me ssh login to your box, it should simplify matters.

You already have an account because YOUR box is 'my' box :)

mysqldev@origin:~> last
mysqldev ttyq1        xxxxxx.mysql.com      Mon Feb  9 23:28 - 23:31  (00:03)
mysqldev ttyq3        xxxxxx.mysql.com      Mon Feb  9 23:05 - 23:32  (00:26)

regards
Joerg

It's very handy that our boxes are the same :)
The reason for the bug is that bison on your machine fails to find m4, because m4 is not installed in the standard (for bison) path "/usr/sbin/m4".
Normally configure script finds m4 and exports M4 variable so bison can use it.
But we recently updated our aclocal.m4, ltmain.sh scripts, and you have an old autoconf (2.13), so your autotools and our scripts apparently fail to work well together.

Possible solutions for the problem are:
- make a symlink /usr/sbin/m4 -> `which m4`
- export M4=`which m4`
- use configure script made by autoconf 2.57, automake 1.7.6, libtool 1.5 or later (I've got 
such versions of these packages, and they create good 'configure' script
- use 'configure' from our source package, instead of making one from BitKeeper .in/.am sources.

I tried last three approaches and they worked, so I close this bug by as  'Not a bug'.
Feel free to reopen it if you have feedback - no need to create new bug entry.

Thx for spending time on this and find it out whats going wrong.

> It's very handy that our boxes are the same :)

The world is small :)

> The reason for the bug is that bison on your machine fails to find m4,
> because m4 is not installed in the standard (for bison) path "/usr/sbin/m4".

In this special case it was a misconfiguration. m4 is part of the Irix OS.
[origin]:~ $ versions long | grep 'bin/m4'
f 10476    89 eoe.sw.base             sbin/m4
l     0     0 eoe.sw.base             usr/bin/m4

and there was already a misconfigurated symlink in usr/sbin/ to the installed GNU Version of m4. I have slaped the admin for that failure.

> Normally configure script finds m4 and exports M4 variable so bison can use
> it.
> But we recently updated our aclocal.m4, ltmain.sh scripts, and you have an old
> autoconf (2.13), so your autotools and our scripts apparently fail to work
> well together.

Lenz told me that he installed all needed things. This can explain the difference in the environments and why you're able to compile it without such those problems.

'We' need autoconf-2.13 for the PHP - QA test because its known as working version for our builds.

> Possible solutions for the problem are:
> - make a symlink /usr/sbin/m4 -> `which m4`

I have used this for a workaround.

> use 'configure' from our source package, instead of making one from BitKeeper
> .in/.am sources.

To avoid more auto* related problems i'll use the configure script from the 'latest snapshot side' nexttime.

Currently the 64bit build compiles fine and the mysqld is up and runing. 

regards
Joerg