MySQL Bugs: #42655: Build looks for no longer existing mysqltest.c

Bug #42655	Build looks for no longer existing mysqltest.c
Submitted:	6 Feb 2009 17:13	Modified:	7 Feb 2009 14:20
Reporter:	Paul DuBois	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Compiling	Severity:	S3 (Non-critical)
Version:	5.1, 6.0 bzr trees	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
The client directory no longer contains mysqltest.c. (I guess it was renamed to mysqltest.cc).

But in libmysqld/examples, the build looks for mysqltest.c, which is symlinked to the non-existent client/mysqltest.c:

make[4]: Entering directory `/src/extern/MySQL/bzr-mysql/mysql-5.1/libmysqld/examples'
make[4]: *** No rule to make target `mysqltest.c', needed by `mysqltest.o'.  Stop.

ls -l shows:

lrwxrwxrwx 1 paul devel    24 2009-01-16 14:19 mysqltest.c -> ../../client/mysqltest.c

So make wants to use a file that cannot be found.

How to repeat:
Configure and build a recent pull of the 5.1 or 6.0 bzr trees.  Here is my build script, on the off chance that the problem is due to my flags:

VERSION=50132

PREFIX="/var/mysql/$VERSION"
PORT=$VERSION
HANDLERS="
  --with-archive-storage-engine
  --with-blackhole-storage-engine
  --with-csv-storage-engine
  --with-example-storage-engine
  --with-federated-storage-engine
  --with-innodb
"
BENCH="--without-bench"
DOCS="--without-docs --without-man"
OTHER="
  --enable-community-features
  --enable-profiling
  --enable-local-infile
  --enable-thread-safe-client
  --with-comment=
  --with-debug=full
  --with-embedded-server
  --with-extra-charsets=all
  --with-partition
  --with-readline
  --with-row-based-replication
  --with-ssl
  --with-client-ldflags=-all-static
  --with-mysqld-ldflags=-all-static
"
rm -f config.cache
CFLAGS=-O1 \
./configure \
  --prefix=$PREFIX \
  --localstatedir=$PREFIX/data \
  --with-unix-socket-path=$PREFIX/mysql.sock \
  --with-tcp-port=$PORT \
  $HANDLERS $BENCH $DOCS $OTHER

Thank you for the report.

Verified as described.

In my environment repeatable only with 5.1 tree on Mac. Not repeatable on Linux.

Happens to me on Mac OS X and Gentoo Linux.

Observed with mysql-6.0 and child branches as well (on Solaris) after pulling big MTR changes (v1 --> v2) into an existing branch, see:

http://lists.mysql.com/falcon/485

Workaround for me was to re-branch or manually delete libmysqld/examples/mysqltest.c symlink.

This is not (really) a bug.

The symbolic link is created during the build process. When the name of the file was changed, the part of the Makefile that is responsible for this was also changed. The described behaviour occurs when there is a mysqltest.c symbolic link still in place that was created during a previous build from before the file was renamed. Since there is no explicit rule for mysqltest.o, and we list ".c" first in .SUFFIXES, a POSIXly correct make implementation will try to build mysqltest.o from mysqltest.c first, before trying mysqltest.cc. Hence, the outdated symbolic link must be removed manually, causing make to pick up the correct source file. Running "make clean" before pulling, or running configure, should also take care of removing the link. However, "make clean" after the Makefile in this directory is updated by configure will not result in the bad link being removed.

Newly created branches will not exhibit the described behaviour.

Workaround for branches that are already broken: Remove libmysqld/examples/mysqltest.c.

Confirming workaround: Manually removing the libmysqld/examples/mysqltest.c symlink resulted in a successful build, for 5.1 and 6.0, on both Mac OS X and Gentoo.

Note: I had previously tried make distclean, but that did not fix the problem.

My guess is you see this only when you pull and you've done make before... make clean or make distclean will not fix it...

either make a fresh clone... or delete the mysqltest.c in the libmysqld dir...

atleast worked for me...

T

make clean will prevent it if you run it *before* pulling.