MySQL Bugs: #23701: MacOS X prebuilt packages should be universal binary

Bug #23701	MacOS X prebuilt packages should be universal binary
Submitted:	27 Oct 2006 0:14	Modified:	17 Aug 2017 8:50
Reporter:	Andreas Fink	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: Packaging	Severity:	S4 (Feature request)
Version:	5.0.26	OS:	MacOS (MacOS X 10.4.8)
Assigned to:		CPU Architecture:	Any

Description:
MacOS X pkg's from website should be universal binaries.
Even its ok for production use to use the right binary version, a developer who builds applications can not use it because his applications are most probably universal binary and then linking against mysqlclient library will fail.

How to repeat:
install package

$ file /usr/local/mysql/lib/mysql/libmysqlclient.a

will show simple archive. 

it should show (as when I compile it from source)

/usr/local/mysql/lib/mysql/libmysqlclient.a: Mach-O universal binary with 4 architectures
/usr/local/mysql/lib/mysql/libmysqlclient.a (for architecture ppc):     current ar archive
/usr/local/mysql/lib/mysql/libmysqlclient.a (for architecture ppc64):   current ar archive
/usr/local/mysql/lib/mysql/libmysqlclient.a (for architecture i386):    current ar archive random library
/usr/local/mysql/lib/mysql/libmysqlclient.a (for architecture x86_64):  current ar archive

Suggested fix:
Compile as universal binary before creating the package.

I do it like this

export PATH="/usr/X11R6/bin:/usr/bin:/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin" 
export LDFLAGS="-lz -liconv" 
export CFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk" 
export CPPFLAGS="" 

./configure --prefix=/usr/local/mysql --disable-dependency-tracking --enable-thread-safe-client --enable-local-infile --enable-largefile --with-extra-charsets=complex --with-innodb --with-berkeley-db --with-big-tables --with-unix-socket-path=/tmp/mysql.sock --with-ndb-shm --with-ndb-port --with-ndb-port-base --with-comment --with-gnu-ld --disable-shared

Under 5.0.27:

export PATH="/usr/X11R6/bin:/usr/bin:/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin"
export LDFLAGS="-lz" 
export CC=gcc
export CFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -fno-omit-frame-pointer -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk" 
export CPPFLAGS="" 
export CXX=gcc
export CXXFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -fno-omit-frame-pointer -fno-exceptions -fno-rtti -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk" 

./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-local-infile --disable-shared --disable-dependency-tracking --enable-thread-safe-client  --enable-largefile --with-innodb --with-berkeley-db --with-big-tables --with-unix-socket-path=/tmp/mysql.sock --with-ndb-shm --with-ndb-port --with-ndb-port-base --with-comment --with-gnu-ld 

compiles a universal binary for all the architectures. Issue was that CXXFLAGS had to be set as well so the C++ code compiles properly too. The produced powerpc version still has an issue with endianness (see separate bug 25060).

So this bug should stay open because the build script doesn't try to build for multiple architectures and/or it doesn't link against the SDK.

Thank you for the reasonable feature request.

But I would like to rephrase it to "MySQL download page should contain universal binary package for Mac"

Sorry this feature request didn't get attention ... - we should have closed it long ago:

Since versions 5.0.40 (enterprise) and 5.0.41 (community, May 2007), we build and publish "universal" packages for OS X 10.4

This bug should be reopened.  The current downloads page:

http://dev.mysql.com/downloads/mysql/

does not contain universal binaries for version 5.5 and Mac OS X v10.6.

More to the point, you shouldn't be shipping non-universal binaries, period.  There's no good reason to even ship the single-architecture 32-bit or 64-bit tarballs.  If any sysadmin is sufficiently concerned about a couple of megabytes of space, it is trivial to use "strip" to remove slices from the binaries.  It's a heck of a lot harder to lipo two tarballs together by hand to get something that will actually work universally.

This bug is still present. I just tested a few minutes ago. After installing the 64bit DMG package I end up having this:

airforce1:~ afink$ file /usr/local/mysql-5.5.25-osx10.6-x86_64/lib/libmysqlclient_r.a
/usr/local/mysql-5.5.25-osx10.6-x86_64/lib/libmysqlclient_r.a: current ar archive random library

This is a single architecture, not dual.
This means if you compile an application for use of mysql, then you have to install the 32bit version, save the libraries somewhere, then install the 64bit versions and then use lipo to merge them together. A very time consuming task just that I can compile my own application for 32/64bit. And if I want to support even older MacOS X hardware such as PowerPC XServes I have to add 32bit and 64bit power PC versions too. So 4 times the hassle.

This bug is definitively still open

Thank you for the feedback.

But MacOS 10.6 does not support PowerPC architecture anymore. Although it supports PowerPC software, I don't think this is good idea to build MySQL just for that. Also PowerPC is not supported platform for MySQL on MacOS anymore. Therefore this would not be fixed.

You can see list of supported platforms at http://www.mysql.com/support/supportedplatforms/database.html

You can also build universal binaries yourself using instructions here: http://geert.vanderkelen.org/building-mysql-universal-binaries-using-macos-x-10-6-snow-leo...

You totally misread my comment. If you install the server on Platform X then it's ok to only install Platform X binaries. And if you dont want to build PowerPC code anymore, that's fine too.

However what is more important is that the CLIENT side is multi platform. Developers build applications which do run on 10.4-10.7 for 4 architectures and the ones which target 10.6 upwards, they will have 2 platforms. So in this case it is vital to have all architectures in the libraries as they are dynamically linked. So if I produce a i386 binary today, it can not link on my mac because the mysql.dylib is x86_64 only. However the person who might use my app might only have a intel core CPU and thus can not run x86_64 and thus nothing works. The only solution is to produce binaries for i386 and x86_64 in one fat library like everybody does.

Thank you for the feedback.

But this is something different from reported in year 2006 and fixed for past version. We also don't support such package for any platform. But we can consider. Please open separate feature request with words from your last comment.

the original bugreport is still correct. the only difference is that we are now on version 5.5 but it applies to all versions

Posted by developer:
 
Thanks for the report, and our apologies for not driving this to closure a long time ago. Closing now, since currently supported Mac OS versions are now 64 bit only.