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

[10 Nov 2004 17:18] Stanley Goldman
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
[11 Nov 2004 18:35] Miguel Solorzano
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)
[17 Nov 2004 19:23] Adam Greenfield
I am experiencing the same issue with the 4.0.22 SRPM, it isn't limited to the 4.1 tree
[17 Nov 2004 19:27] Adam Greenfield
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
[17 Nov 2004 20:20] Lenz Grimmer
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!
[17 Nov 2004 21:00] Adam Greenfield
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
[18 Nov 2004 8:15] Lenz Grimmer
Adam, thanks a lot! I will download these from your location and attach them myself. Sorry for the inconvenience.
[18 Nov 2004 8:15] Lenz Grimmer
Build log on FC2 (works)

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

[18 Nov 2004 8:15] Lenz Grimmer
Build log on FC3 (does not work)

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

[18 Nov 2004 11:08] Lenz Grimmer
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?
[18 Nov 2004 15:15] Adam Greenfield
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/
[18 Nov 2004 15:59] Lenz Grimmer
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.
[18 Nov 2004 16:18] Adam Greenfield
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
[19 Nov 2004 6:41] Miguel Solorzano
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.
[25 Nov 2004 9:31] Daniel Lacroix
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/
[25 Nov 2004 10:04] Lenz Grimmer
Bug#6769 was marked as a duplicate of this one.
[25 Nov 2004 12:40] Sergei Golubchik
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
[15 Jan 2005 12:40] Thomas Zehetbauer
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
[8 Feb 2005 22:32] Matthew Daniel
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.
[10 Feb 2005 0:14] Matthew Daniel
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).
[11 Mar 2005 4:31] [ name withheld ]
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
[14 Mar 2005 11:08] 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/internals/22988
[14 Mar 2005 15:28] Magnus Blåudd
The supplied patch works fine for 4.1. But in 5.0 there are some other places that uses local static variables.
[21 Mar 2005 11:29] 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/internals/23226
[1 Apr 2005 10:33] 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/internals/23558
[1 Apr 2005 10:43] Magnus Blåudd
This problem has now been fixed in 4.0.25, 4.1.11 and 5.0.4
[5 Apr 2005 0:20] Paul Dubois
Noted in 4.0.25, 4.1.11, 5.0.4 changelogs.
[13 Jan 2006 13:20] Hartmut Holzgraefe
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)
[16 Jan 2006 11:17] 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/1133
[16 Jan 2006 13:45] Magnus Blåudd
Pushed to 4.0.27, already present in 4.1 and up.
[16 Jan 2006 21:53] Mike Hillyer
Moved changelog entry from 4.0.25 to 4.0.27.
[15 Jul 2009 9:15] assad zaman
gggggggggggggggggggggggggggggggggggggggggggg
[15 Jul 2009 9:17] assad zaman
unable to install  mysql 5.1x to fedora 10