MySQL Bugs: #6554: Problem Building MySql on Fedora Core 3

Bug #6554	Problem Building MySql on Fedora Core 3
Submitted:	10 Nov 2004 17:18	Modified:	16 Jan 2006 21:53
Reporter:	Stanley Goldman	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Compiling	Severity:	S2 (Serious)
Version:	4.1.7	OS:	Linux (Fedora Core 3)
Assigned to:	Magnus Blåudd	CPU Architecture:	Any

Description:
Attempts to build MySql 4.1.7 from src rpm fail with the following...
gcc-3.4.2-6.fc3
kernel-2.6.9-1.667

produces the following...
gcc -O3 -DDBUG_OFF -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -felide-constructors -fno-exceptions -fno-rtti -fno-implicit-templates -fno-exceptions -fno-rtti -DUSE_MYSYS_NEW -DDEFINE_CXA_PURE_VIRTUAL -rdynamic -o mysqld sql_lex.o sql_handler.o item.o item_sum.o item_buff.o item_func.o item_cmpfunc.o item_strfunc.o item_timefunc.o thr_malloc.o item_create.o item_subselect.o item_row.o item_geofunc.o field.o strfunc.o key.o sql_class.o sql_list.o net_serv.o protocol.o sql_state.o lock.o my_lock.o sql_string.o sql_manager.o sql_map.o mysqld.o password.o hash_filo.o hostname.o set_var.o sql_parse.o sql_yacc.o sql_base.o table.o sql_select.o sql_insert.o sql_prepare.o sql_error.o sql_update.o sql_delete.o uniques.o sql_do.o procedure.o item_uniq.o sql_test.o log.o log_event.o init.o derror.o sql_acl.o unireg.o des_key_file.o discover.o time.o opt_range.o opt_sum.o records.o filesort.o handler.o ha_heap.o ha_myisam.o ha_myisammrg.o ha_berkeley.o ha_innodb.o ha_isam.o ha_isammrg.o ha_ndbcluster.o sql_db.o sql_table.o sql_rename.o sql_crypt.o sql_load.o mf_iocache.o field_conv.o sql_show.o sql_udf.o sql_analyse.o sql_cache.o slave.o sql_repl.o sql_union.o sql_derived.o client.o sql_client.o mini_client_errors.o pack.o stacktrace.o repl_failsafe.o gstream.o spatial.o sql_help.o protocol_cursor.o tztime.o my_time.o ha_example.o ha_archive.o ha_tina.o  -L/usr/src/redhat/BUILD/mysql-4.1.7/bdb/build_unix -ldb ../innobase/usr/libusr.a ../innobase/srv/libsrv.a ../innobase/dict/libdict.a ../innobase/que/libque.a ../innobase/srv/libsrv.a ../innobase/ibuf/libibuf.a ../innobase/row/librow.a ../innobase/pars/libpars.a ../innobase/btr/libbtr.a ../innobase/trx/libtrx.a ../innobase/read/libread.a ../innobase/usr/libusr.a ../innobase/buf/libbuf.a ../innobase/ibuf/libibuf.a ../innobase/eval/libeval.a ../innobase/log/liblog.a ../innobase/fsp/libfsp.a ../innobase/fut/libfut.a ../innobase/fil/libfil.a ../innobase/lock/liblock.a ../innobase/mtr/libmtr.a ../innobase/page/libpage.a ../innobase/rem/librem.a ../innobase/thr/libthr.a ../innobase/sync/libsync.a ../innobase/data/libdata.a ../innobase/mach/libmach.a ../innobase/ha/libha.a ../innobase/dyn/libdyn.a ../innobase/mem/libmem.a ../innobase/sync/libsync.a ../innobase/ut/libut.a ../innobase/os/libos.a ../innobase/ut/libut.a -lrt ../myisam/libmyisam.a ../myisammrg/libmyisammrg.a ../heap/libheap.a ../vio/libvio.a ../mysys/libmysys.a ../dbug/libdbug.a ../regex/libregex.a ../strings/libmystrings.a -lz -ldl -lpthread -lcrypt -lnsl -lm -lpthread
ha_berkeley.o(.text+0x720): In function `ha_berkeley::bas_ext() const':
/usr/src/redhat/BUILD/mysql-4.1.7/sql/ha_berkeley.cc:340: undefined reference to `__cxa_guard_acquire'
ha_berkeley.o(.text+0x73a):/usr/src/redhat/BUILD/mysql-4.1.7/sql/ha_berkeley.cc:340: undefined reference to `__cxa_guard_release'
collect2: ld returned 1 exit status
make[4]: *** [mysqld] Error 1
make[4]: Leaving directory `/usr/src/redhat/BUILD/mysql-4.1.7/sql'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/src/redhat/BUILD/mysql-4.1.7/sql'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/src/redhat/BUILD/mysql-4.1.7/sql'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/mysql-4.1.7'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.28662 (%build)

How to repeat:
rpmbuild --rebuild http://ftp.iasi.roedu.net/mirrors/ftp.mysql.com/MySQL-4.1/MySQL-4.1.7-0.src.rpm

Tested on fresh Fedora install box. 
 
collect2: ld returned 1 exit status 
make[4]: *** [mysqld] Error 1 
make[4]: Leaving directory `/usr/src/redhat/BUILD/mysql-4.1.7/sql' 
make[3]: *** [all-recursive] Error 1 
make[3]: Leaving directory `/usr/src/redhat/BUILD/mysql-4.1.7/sql' 
make[2]: *** [all] Error 2 
make[2]: Leaving directory `/usr/src/redhat/BUILD/mysql-4.1.7/sql' 
make[1]: *** [all-recursive] Error 1 
make[1]: Leaving directory `/usr/src/redhat/BUILD/mysql-4.1.7' 
make: *** [all] Error 2 
error: Bad exit status from /var/tmp/rpm-tmp.81449 (%build)

I am experiencing the same issue with the 4.0.22 SRPM, it isn't limited to the 4.1 tree

Sorry, should have included this in my original comment:
It is specific to Fedora Core 3, the SRPM builds properly on FC1 and FC2, here is a list of the "db" related rpms I have installed, as the error message indicates this is likely an issue with berkley db:

FC3 (NOT working):
dbh-1.0.18-5
db4-4.2.52-6
db4-devel-4.2.52-6
gdbm-devel-1.8.0-24
dbh-devel-1.0.18-5
gdbm-1.8.0-24
db4-utils-4.2.52-6
db4-tcl-4.2.52-6

FC2 (working):
gdbm-1.8.0-22.1
db4-4.2.52-3.1
db4-utils-4.2.52-3.1
gdbm-devel-1.8.0-22.1
db4-devel-4.2.52-3.1

Thanks a lot for the thorough investigation! Would it be possible for you to attach the complete compile log files for both a successful and a failed compile? I suspect that there is a problem when compiling the included BDB, if different BDB header files are installed in the system.

Thanks in advance!

I tried to properly attach the logs, however I recieved the following error "Only registered developers and the original submitter are allowed to attach files to the bug."
I threw the logs up on our webspace, let me know if you would rather I send them some other way
FC2 (works):
http://people.jtlnet.com/~adam/fc2-mysql-build.log

FC3 (doesn't work):
http://people.jtlnet.com/~adam/fc3-mysql-build.log

Adam, thanks a lot! I will download these from your location and attach them myself. Sorry for the inconvenience.

Build log on FC2 (works)

Attachment: fc2-mysql-build.log.gz (application/x-gzip, text), 151.32 KiB.

Build log on FC3 (does not work)

Attachment: fc3-mysql-build.log.gz (application/x-gzip, text), 84.40 KiB.

I have taken a look at the diff between the two build runs. The major difference I could notice between FC2 and FC3 are the following:

FC2 uses gcc-3.3.3, FC3 has updated to gcc-3.4.2 - maybe the Berkeley DB sources included in the MySQL distribution need to be updated to compile with gcc-3.4.2?

The RPM_OPT_FLAGS between FC2 and FC3 differ, too:
FC2: -O2 -g -pipe -march=i386 -mcpu=i686
FC3: -O2 -g -pipe -m32 -march=i386 -mtune=pentium4

Seems like either the compiler version or one of the new compiler flags causes this problem.
For the time being, a workaround would be to disable the compiling of BDB in the RPM spec file. Look for the configure option "--with-berkeley-db" inside the spec file and change it to "--without-berkeley-db". That should skip the offending part in the build.

We will need to investigate this further and update BDB or fix this specific problem in the BDB sources. Does the BDB RPM in FC3 include any patches that look like they fix a compiler-specific problem?

Ok, I've gone over the SPEC file for FC3 and they include a number of patches (10 to be exact), however none of them appear to be working around a compiler issue. Several seem to relate only to db4-java. 

Here are the patches added between FC2 and FC3:
== http://people.jtlnet.com/~adam/mysqlbug-6554/fc3-db4/patch.4.2.52.1 ==
Seems to address a threading issue, moves a MUTEX_LOCK statement down a bit

== http://people.jtlnet.com/~adam/mysqlbug-6554/fc3-db4/patch.4.2.52.2 ==
Patches lock/lock.c changes the COPY_OBJ pre-processor macro, and changes slightly the way it is invoked.

== http://people.jtlnet.com/~adam/mysqlbug-6554/fc3-db4/db-4.2.52-gcj.patch ==
== http://people.jtlnet.com/~adam/mysqlbug-6554/fc3-db4/db-4.2.52-java.patch ==
Both these patches seem only to apply to the -java related code.

======================================================================
There is one patch that was removed (existed in FC2, doesn't in FC3), but I don't believe the changes made there would cause the issue we are seeing here. The changes the patch make may even have been pushed upstream between versions. It is http://people.jtlnet.com/~adam/mysqlbug-6554/fc2-db4/db-4.1.25-jbj.patch

======================================================================
Here is a diff file from db4.spec in FC2 to db4.spec in FC3
http://people.jtlnet.com/~adam/mysqlbug-6554/db4-spec-file.diff

======================================================================
And here are the new change log entries in the bottom of the SPEC
> * Tue Sep 21 2004 Nalin Dahyabhai <nalin@redhat.com> 4.2.52-6
> - on %%{ix86} systems, make the availability of an NPTL-requiring libdb match
>   the availability of an NPTL libpthread in glibc > 2.3.3-48
> - run ldconfig in db4-java's %%post/%%postun
> - when building java support, assume that libgcj is equivalent enough to 1.3
> 
> * Tue Jun 15 2004 Elliot Lee <sopwith@redhat.com>
> - rebuilt
> 
> * Mon Jun  7 2004 Jeff Johnson <jbj@jbj.org> 4.2.52-4
> - remove dangling symlinks (#123721 et al).
> - remove db_cxx.so and db_tcl.so symlinks, versioned equivs exist.
> - apply 2 patches from sleepycat.
> - resurrect db4-java using sun jvm-1.4.2.
> - cripple autoconf sufficiently to build db4-java with gcj, without jvm.
> - check javac first, gcj34 next, then gcj-ssa, finally gcj.
> - add ed build dependency (#125180).
> 
======================================================================
I don't see anything here that looks promising, below are the links to the two exploded SRPMS
http://people.jtlnet.com/~adam/mysqlbug-6554/fc2-db4/
http://people.jtlnet.com/~adam/mysqlbug-6554/fc3-db4/

Thanks a lot for your help Adam! It's appreciated. Ramil, you have been working on BDB in MySQL before - would you mind taking a look at this? Please verify if we need to update BDB or if this can be fixed in some other way.

The version of BDB actually didn't change between FC2 and FC3 (both use 4.2.52), however I think we may be going the wrong direction, a little Google-searching on the function at the root of the error "__cxa_guard_release" seems to point to libstdc++ which got a big bump between FC2 and FC3.

[root@fc2 root]# rpm -qa | grep libstdc
libstdc++-3.3.3-7
libstdc++-devel-3.3.3-7

[root@fc3 ~]# rpm -qa | grep libstdc
libstdc++-3.4.2-6.fc3
libstdc++-devel-3.4.2-6.fc3
compat-libstdc++-8-3.3.4.2

For the record: I got the same behavior on Fedora C3 when compiling
the source BK 4.1/5.0. Failing like showed below:

ha_ndbcluster.o(.text+0x888d): In function `ha_ndbcluster::bas_ext() const':
/home/miguel/bk/mysql-5.0/sql/ha_ndbcluster.cc:2790: undefined reference to `__cxa_guard_acquire'
ha_ndbcluster.o(.text+0x88a7):/home/miguel/bk/mysql-5.0/sql/ha_ndbcluster.cc:2790: undefined reference to `__cxa_guard_release'
collect2: ld returned 1 exit status
make[4]: *** [mysqld] Error 1
make[4]: Leaving directory `/home/miguel/bk/mysql-5.0/sql'
make[3]: *** [all-recursive] Error 1

ha_ndbcluster.o(.text+0x87d5): In function `ha_ndbcluster::bas_ext() const':
/home/miguel/bk/mysql-4.1/sql/ha_ndbcluster.cc:2780: undefined reference to `__cxa_guard_acquire'
ha_ndbcluster.o(.text+0x87ef):/home/miguel/bk/mysql-4.1/sql/ha_ndbcluster.cc:2780: undefined reference to `__cxa_guard_release'
collect2: ld returned 1 exit status
make[4]: *** [mysqld] Error 1
make[4]: Leaving directory `/home/miguel/bk/mysql-4.1/sql'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/miguel/bk/mysql-4.1/sql'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/miguel/bk/mysql-4.1/sql'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/miguel/bk/mysql-4.1'
make: *** [all] Error 2
[miguel@light mysql-4.1]$                      

ha_berkeley.o(.text+0xb39): In function `ha_berkeley::bas_ext() const':
/home/miguel/bk/mysql-5.0/sql/ha_berkeley.cc:342: undefined reference to `__cxa_guard_acquire'
ha_berkeley.o(.text+0xb53):/home/miguel/bk/mysql-5.0/sql/ha_berkeley.cc:342: undefined reference to `__cxa_guard_release'
collect2: ld returned 1 exit status
gmake[4]: *** [mysqld] Error 1
gmake[4]: Leaving directory `/home/miguel/bk/mysql-5.0/sql'

Searching I found that those symbols belongs to c++-abi stuf, then
I downloaded the source of GCC++ 3.4.2 and build it with the configure
options mentioned at:

http://www.gnu.org/software/gcc/gcc-3.2/c++-abi.html

Installed the above GCC++ stuff, done a make clean and ./configure on
MySQL source tree 5.0 and I was able for to compile, install and
start mysqld without any problems. I didn't run the test suite on
MySQL.

I also have try to compile MySQL 4.1.7 on FC3 and got the same problem. To solve the problem I added the following lines in the "configure" script. 

25127a25128,25134
> #
> # Added by Daniel Lacroix 20041124 for compile problem
> # on Fedora Core 3
> #
>
> LIBS="$LIBS -lsupc++"

I think this is certainly not the best/good place but it works.

Resulting packages are available here: ftp://ftp.erasme.org/pub/linux/dist/fedora/erasme/3/RPMS/

Bug#6769 was marked as a duplicate of this one.

besides new, delete, and __cxx_pure_virtual (that should be moved to my_new.cc) there are more stubs to implement to be able to use CXX=gcc. see http://www.codesourcery.com/cxx-abi/ for details.

using -lstdc++ could be a solution too

The problem persists with MySQL-4.1.9. I have put the build log at http://www.hostmaster.org/~thomasz/MySQL-4.1.9-rebuild.txt

The comment by Daniel is a great example of why I hate contextual diffs. If it were unified, then I could at least guess where it should go in the most current configure.in.

Can someone from MySQL comment on that work-around, whether it works and if so where that line should be inserted in configure.in?

I am running FC3 (x86_64) and am experiencing the exact same issue with today's bk pull.

Building upon Daniel's comment and some more reading,

patch << EOD
===== sql/Makefile.am 1.111 vs edited =====
--- 1.111/sql/Makefile.am       2004-09-16 03:21:41 -04:00
+++ edited/sql/Makefile.am      2005-02-09 18:20:13 -05:00
@@ -29,7 +29,7 @@
 noinst_PROGRAMS =      gen_lex_hash
 bin_PROGRAMS =         mysql_tzinfo_to_sql
 gen_lex_hash_LDFLAGS =  @NOINST_LDFLAGS@
-LDADD =                        @isam_libs@ \
+LDADD =         -lsupc++ @isam_libs@ \
                        $(top_builddir)/myisam/libmyisam.a \
                        $(top_builddir)/myisammrg/libmyisammrg.a \
                        $(top_builddir)/heap/libheap.a \
EOD

causes today's pull to build. At least, It Works For Me(tm).

The simplest thing to do is use g++ (instead of gcc) to link the code.  As long as -fno-rtti and -fno-exceptions are passed on the command-line, the reasons for using gcc over g++ to compile/link are moot.

I am on an FC3/x86_64 box using MySQL-4.1.10-0.src.rpm.  Simply modify CXX=gcc to CXX=g++ in /usr/src/redhat/SPECS/mysql-4.1.10.spec (just above the BuildMySQL for -Max), then 'rpmbuild -bb mysql-4.1.10.spec'.  Takes about 5 minutes to build the binary RPMS on 4 CPUs (parallel builds require another simple change to the spec file).

Hope this helps,
Cheers,
Demian

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/internals/22988

The supplied patch works fine for 4.1. But in 5.0 there are some other places that uses local static variables.

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/internals/23226

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/internals/23558

This problem has now been fixed in 4.0.25, 4.1.11 and 5.0.4

Noted in 4.0.25, 4.1.11, 5.0.4 changelogs.

Hi Magnus, 
it looks as if the changeset for 4.0 has never been pushed to the 4.0 tree?
(bug status set back to "patch pending" for now)

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/1133

Pushed to 4.0.27, already present in 4.1 and up.

Moved changelog entry from 4.0.25 to 4.0.27.

gggggggggggggggggggggggggggggggggggggggggggg

unable to install  mysql 5.1x to fedora 10