4-Way Universal Binary MySQL for Leopard Configuration
Mac OS X — 14 Nov 2007 10:54 — 1542 days ago

MySQL seems to build as a four-way universal binary out of the box on Leopard using a configure line like this:

MACOSX_DEPLOYMENT_TARGET=10.5 \ CFLAGS='-arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \ LDFLAGS='-arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \ CXXFLAGS='-arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \ ./configure --disable-dependency-tracking --prefix=/usr/local/mysql

Followed by make and make install, I get a MySQL that seems to be complete.


Comments
Posted by m.Sharp on 15 Nov 2007 04:44

Thanks a lot! That resolve my problem for compiling the 4-way universal PHP package!

But I have a question... can I do the same thing for 10.4 systems, or can I compile PHP on a 10.4 system like this?

Thanks!

Posted by Leo Studer on 19 Nov 2007 15:41

Am I correct, when I need only the x86_64 version, then I set the flags only for this arch? Why do I then get an error with make?

Posted by Marc Liyanage on 19 Nov 2007 16:17

Leo: I'd have to see the error message.

But in general, if you simply want to build for the architecture on which the build runs, then you don't have to use any arch flags.

Without arch flags, it will use the architecture on which you run configure/make.

Posted by Leo Studer on 20 Nov 2007 16:38

Marc, thanks for the clarification. I was worried because I first built mysql for multi platforms as you suggested and all went well. Then only for the core 2 duo and got errors during make. Now I used a new download and started from scratch. Everything is fine now...

However, PHP is still not complete... :)

Posted by Tony Arnold on 3 Dec 2007 14:03

Marc, have you tried this using the latest release candidate of MySQL 5.1? (I believe it's 5.1.22).

Mine bails with the following error:

g++ -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME="\"/usr/local/mysql\"" -DDATADIR="\"/usr/local/mysql/var\"" -DSHAREDIR="\"/usr/local/mysql/share/mysql\"" -DLIBDIR="\"/usr/local/mysql/lib/mysql\"" -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../include -I../regex -I. -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64 -fno-implicit-templates -fno-exceptions -fno-rtti -D_P1003_1B_VISIBLE -DSIGNAL_WITH_VIO_CLOSE -DSIGNALS_DONT_BREAK_READ -DIGNORE_SIGHUP_SIGQUIT -DDONT_DECLARE_CXA_PURE_VIRTUAL -c -o sql_plugin.o sql_plugin.cc
sql_plugin.cc: In function ‘void plugin_opt_set_limits(my_option*, const st_mysql_sys_var*)’:
sql_plugin.cc:2723: error: cast from ‘char*’ to ‘intptr’ loses precision
sql_plugin.cc:2765: error: cast from ‘char*’ to ‘intptr’ loses precision
sql_plugin.cc: In function ‘void plugin_opt_set_limits(my_option*, const st_mysql_sys_var*)’:
sql_plugin.cc:2723: error: cast from ‘char*’ to ‘intptr’ loses precision
sql_plugin.cc:2765: error: cast from ‘char*’ to ‘intptr’ loses precision
lipo: can't figure out the architecture type of: /var/folders/Wr/WrsfA5dqGIq8-hcQZFxjwk+++TI/-Tmp-//ccCXuGdG.out
make[3]: *** [sql_plugin.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1

Posted by Marc Liyanage on 4 Dec 2007 00:46

Tony: Exactly the same happens here. I'm pretty sure it worked with an earlier build (5.0.45). You might want to report that as a bug to MySQL...

Posted by Leo Studer on 4 Dec 2007 10:44

Tony and Marc. With 5.0.45 it works fine here... I have not tried 5.1...

Posted by Marc Liyanage on 5 Dec 2007 09:59

Leo: We *know* it works with 5.0. And we know the 5.1 Release Candidate doesn't work, which is what we're discussing here.

Posted by Tony Arnold on 12 Jan 2008 13:10

I finally got around to filing the bug at MySQL.com. It is under bug #33830:

http://bugs.mysql.com/bug.php?id=33830

Posted by mogga on 23 Jan 2008 19:06

i found this...

http://hivelogic.com/articles/installing-mysql-on-mac-os-x/

seems to work but now the libraries are the wrong architecture for compiling mysql-python
trying your method...
argh!

Powered By blojsom