Bug #26218 Build failure on Intel Mac
Submitted: 9 Feb 2007 11:43 Modified: 3 Aug 2007 16:28
Reporter: Sveta Smirnova Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: Compiling Severity:S3 (Non-critical)
Version:5.0 BK, 4.1 BK OS:MacOS (Mac OS X)
Assigned to: Kent Boortz CPU Architecture:Any

[9 Feb 2007 11:43] Sveta Smirnova
Compilation of current BK sources fails with message:

/usr/bin/ld: Undefined symbols:

How to repeat:
cd src/mysql-5.0
BUILD/compile-pentium-debug-max or BUILD/compile-ppc-debug-max
[12 Feb 2007 9:43] Sveta Smirnova
Same error with 4.1
[12 Feb 2007 16:01] Mads Martin Joergensen
I quote Kent Boortz here:

"I had the problem you show for month, each time I had to edit by hand
the "libtool" command produced by configure not to output the strange
"~ranlib" addition. I can show you what to edit ;-)

My problem is gone since long, I can't say for 100% sure, but it is
most likely a problem with your mix of "automake" and "libtool". I now

  autoconf        2.59
  automake        1.9.6
  libtool         1.5.22

Note that there are some traps. If you install a new GNU autotool
chain in /usr/local, you have to install them in a specific order, and
make sure /usr/local/bin is in PATH. They write in each others
"/usr/local/share/<package>" and if installed in the wrong order, they
will write in the preinstalled stuff in "/usr/share/<package>"
instead. If I remeber correctly, the order is

  autoconf => automake => libtool

There is another trap. In "BUILD/autorun.sh" there is a test for
"/usr/bin/glibtoolize", and if found it choses "glibtoolize"
without PATH. We should improve that test, but in the mean time
you better be sure that you have a soft link from
"<yourprefix>/bin/glibtoolize" to "<yourprefix>/bin/libtoolize",
else it will not use your newly installed libtool.

Hope this helps, else if you could try reproduce your problem on some
of the build hosts, I can try look closer at it,"
[13 Feb 2007 10:55] Sveta Smirnova
If remove system libtool, I got different error:

ar: can't find or exec: ranlib (No such file or directory)
ar: internal ranlib command failed

Note: I have GNU libtool 1.5.22 installed and which libtool shows me new 1.5.22 libtool
[30 Jul 2007 18:40] 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:


ChangeSet@1.2679, 2007-07-30 20:40:49+02:00, kent@mysql.com +1 -0
    Backport of correction for Mac OS X build problem, global variable not
    initiated is "common" and can't be used in shared libraries, unless
    special flags are used (bug#26218)
[30 Jul 2007 19:14] Kent Boortz
If compiled without --fno-common, global variables
has to be initiated if used to form a shared library.
See "common symbol" in


Tested this out, and found that this had already been
corrected in 5.0. I backported the change to 4.1.
[2 Aug 2007 19:12] Bugs System
Pushed into 5.1.21-beta
[2 Aug 2007 19:15] Bugs System
Pushed into 5.0.48
[2 Aug 2007 19:16] Bugs System
Pushed into 4.1.24
[3 Aug 2007 16:28] Paul DuBois
No changelog entry needed.