Bug #14685 --without-server --with-embedded-library does not build
Submitted: 6 Nov 2005 19:23 Modified: 27 Apr 2007 15:17
Reporter: Philip Stoev Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Compiling Severity:S3 (Non-critical)
Version:5.0.15 OS:Linux (linux)
Assigned to: Joerg Bruehe CPU Architecture:Any

[6 Nov 2005 19:23] Philip Stoev
Description:
using both --without-server and --with-embedded-library options results in a compile-time error because mysqld_error.h is not generated.

How to repeat:
./configure --without-server --with-embedded-library
make

Suggested fix:
The configure script should sound a warning when mutually exclusive options are used. This way confusing compile-time messages will be avoided.

Alternatively, one should be able to build libmysqld without building the server-only parts, such as TCP support. I do agree however that this is kind of over the top.
[6 Nov 2005 22:44] Miguel Solorzano
According with the Manual the option should be --with-embedded-server
instead of with-embedded-library:

http://dev.mysql.com/doc/refman/5.0/en/configure-options.html

 If you want to build the embedded MySQL library (libmysqld.a) you should use the --with-embedded-server option.

However the configure process isn't aborted with invalid option when using
with-embedded-library and in this way I got the issue reported:

libmysql.c:28:26: mysqld_error.h: No such file or directory
make[2]: *** [libmysql.lo] Error 1
make[2]: Leaving directory `/home/miguel/dbs/mysql-5.0/libmysql'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/miguel/dbs/mysql-5.0'
make: *** [all] Error 2
miguel@hegel:~/dbs/mysql-5.0>
[7 Nov 2005 8:05] Philip Stoev
Thank you very much for your response. I filed a separate bug http://bugs.mysql.com/?id=14685 about configure options in general.
[7 Nov 2005 12:10] Miguel Solorzano
I changed to not a bug since you opened another bug regarding
not valid configure options.
[7 Nov 2005 12:58] Philip Stoev
I believe those are two separate bugs. The other bug that I have opened is about the configure script not doing enough checking. This bug is about the fact that ./configure with those two particular options produces a Makefile that does not build mysqld_error.h from the /extras directory. I believe that something in the Makefile system is wrong and is worth fixing.
[7 Nov 2005 13:02] Miguel Solorzano
I was able for to build using the option --with-embedded-server. Did you
try?
[7 Nov 2005 13:23] Philip Stoev
Yes I understand the correct option is --with-embedded-server. This bug has nothing to do with the embedded library. See this:
./configure --witout-server -with-nothing-in-particular
make
Making all in libmysql
make[2]: Entering directory `/usr/src/mysql-5.0.15/libmysql'
if /bin/sh ../libtool --preserve-dup-deps --mode=compile gcc -DDEFAULT_CHARSET_HOME="\"/usr/local\"" -DDATADIR="\"/usr/local/var\"" -DDEFAULT_HOME_ENV=MYSQL_HOME -DDEFAULT_GROUP_SUFFIX_ENV=MYSQL_GROUP_SUFFIX -DSHAREDIR="\"/usr/local/share/mysql\"" -DUNDEF_THREADS_HACK -DDONT_USE_RAID  -I. -I. -I.. -I../include -I../include      -O3 -DDBUG_OFF    -MT libmysql.lo -MD -MP -MF ".deps/libmysql.Tpo" -c -o libmysql.lo libmysql.c; \
then mv -f ".deps/libmysql.Tpo" ".deps/libmysql.Plo"; else rm -f ".deps/libmysql.Tpo"; exit 1; fi
mkdir .libs
 gcc -DDEFAULT_CHARSET_HOME=\"/usr/local\" -DDATADIR=\"/usr/local/var\" -DDEFAULT_HOME_ENV=MYSQL_HOME -DDEFAULT_GROUP_SUFFIX_ENV=MYSQL_GROUP_SUFFIX -DSHAREDIR=\"/usr/local/share/mysql\" -DUNDEF_THREADS_HACK -DDONT_USE_RAID -I. -I. -I.. -I../include -I../include -O3 -DDBUG_OFF -MT libmysql.lo -MD -MP -MF .deps/libmysql.Tpo -c libmysql.c  -fPIC -DPIC -o .libs/libmysql.o
libmysql.c:28:26: error: mysqld_error.h: No such file or directory
make[2]: *** [libmysql.lo] Error 1
make[2]: Leaving directory `/usr/src/mysql-5.0.15/libmysql'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/mysql-5.0.15'
make: *** [all] Error 2

Therefore, it appears that any mistyped or wrong "--with-" option combined with "--without-server" causes the compilation to fail in a totally non-descriptive way. People could possibly waste hours trying to figure out why a misspelled configuration option that does not enable or disable any particular component results in a compilation error like this (as opposed to the compilation being successful however the executable missing the mis-spelled component)

From my testing, it appears that the --without-server option is required to produce this behavoir. Therefore, I think that there is an dependency error in the Makefile system that will likely manifest itself under other circumstances, resulting in the same non-descriptive error message. I did a diff between the configured source trees with and without the option in question, however I could not immediately spot the culpit.
[30 Mar 2006 15:46] Joerg Bruehe
I will take a look at it.
[11 Apr 2006 14:27] Joerg Bruehe
Sorry about the delay, release builds took priority.

Just an interim status:
I could not reproduce the total failure to build,
but it seems that a "configure --without-unknown-blabla --without-server"
silently ignores the valid "--without-server" option and does a full build.

I have to improve my tools for this, to get a log of exactly the interesting part, and will repeat these experiments.
I cannot give an ETA, sorry - too much depends on parallel build requirements.
[11 Apr 2006 19:38] Joerg Bruehe
Went much faster than I had feared:

Using current sources (5.0.20), I could not reproduce the problem.
All the following could be used successfully with a following "make"
which (as instructed) did not build the server:

configure --without-server
configure --without-server --with-unknown-foobar
configure --without-server --without-unknown-foobar
configure --with-unknown-foobar --without-server
configure --without-unknown-foobar --without-server
configure --without-server --with-nothing-in-particular

So "--with-*" as well as "--without-*", either before or after the "--without-server", did not cause problems.
Test machine was Linux, Debian 3.1, with a PPC CPU ("Pegasos").

Please try with current sources, and re-open this bug if you still have problems.
[11 Apr 2006 20:40] Philip Stoev
Thank you very much for your effort.

I will try to provide a repeatable case using the current build and will re-open the bug if successfull.
[21 Jun 2006 20:05] Leif Neve
FWIW, I just tried to build 5.0.22 on Solaris with the --without-server option as in:

 ./configure --without-server
make

and it generates this error:

 gcc -DDEFAULT_CHARSET_HOME=\"/usr/local\" -DDATADIR=\"/usr/local/var\" -DDEFAULT_HOME_ENV=MYSQL_HOME -DDEFAULT_GROUP_SUFFIX_ENV=MYSQL_GROUP_SUFFIX -DDEFAULT_SYSCONFDIR=\"/usr/local/etc\" -DSHAREDIR=\"/usr/local/share/mysql\" -DUNDEF_THREADS_HACK -DDONT_USE_RAID -I. -I. -I.. -I../include -I../include -I../zlib -O3 -DDBUG_OFF -DHAVE_RWLOCK_T -MT libmysql.lo -MD -MP -MF .deps/libmysql.Tpo -c libmysql.c  -fPIC -DPIC -o .libs/libmysql.o
libmysql.c:28:26: mysqld_error.h: No such file or directory
*** Error code 1
make: Fatal error: Command failed for target `libmysql.lo'
Current working directory /opt/mysql-5.0.22/libmysql
[25 Jun 2006 19:18] Daniel Moellenbeck
I can reproduce the same on Debian Linux 3.1:

./configure --prefix=/usr/local/mysql-5.0.22 --without-server
[...]
 gcc -DDEFAULT_CHARSET_HOME=\"/usr/local/mysql-5.0.22\" -DDATADIR=\"/usr/local/mysql-5.0.22/var\" -DDEFAULT_HOME_ENV=MYSQL_HOME -DDEFAULT_GROUP_SUFFIX_ENV=MYSQL_GROUP_SUFFIX -DDEFAULT_SYSCONFDIR=\"/usr/local/mysql-5.0.22/etc\" -DSHAREDIR=\"/usr/local/mysql-5.0.22/share/mysql\" -DUNDEF_THREADS_HACK -DDONT_USE_RAID -I. -I. -I.. -I../include -I../include -O3 -DDBUG_OFF -MT libmysql.lo -MD -MP -MF .deps/libmysql.Tpo -c libmysql.c  -fPIC -DPIC -o .libs/libmysql.o
libmysql.c:28:26: mysqld_error.h: No such file or directory
make[2]: *** [libmysql.lo] Error 1
make[2]: Leaving directory `/usr/local/src/mysql-5.0.22/libmysql'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/mysql-5.0.22'
make: *** [all] Error 2
[23 Apr 2007 11:01] Joerg Bruehe
I re-tried with current sources on Debian 3.1 and still could not reproduce the symptom reported with "mysqld_error.h".

However, I found an issue in "dbug/dbug_analyze.c" which I will fix.
[23 Apr 2007 11:36] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/25102

ChangeSet@1.2460, 2007-04-23 13:36:18+02:00, joerg@debian.(none) +1 -0
  dbug/dbug_analyze.c  :  Avoid the unresolved symbol "my_thread_global_init()"
                          in a build "--without-server".
  
  Fix for bug#14685
[23 Apr 2007 17:34] Joerg Bruehe
Pushed to the team trees,
expect it to be included in 5.0.42 and 5.1.18
[27 Apr 2007 9:22] Bugs System
Pushed into 5.1.18-beta
[27 Apr 2007 9:24] Bugs System
Pushed into 5.0.42
[27 Apr 2007 15:17] Paul Dubois
No changelog entry needed.