I’m stuck with a whole bunch of problems getting code to compile and co-operate nicely on my new MacBookPro. I’m compiling my own PHP, but it defaults to compiling for the i386 (32bit) architecure, which then fails when Apache2 running in 64bit mode tries to use the 32bit DSO for PHP5. Compiling PHP5 as 64bit then fails linking against the i386 pgsql lib, and so on. I really need everything using the x86_64 architecture. How does this all relate to readline under Leopard?

The problem is the Intel Core2 Duo is a 64bit CPU. Apple supplied apps like Apache2 are compiled as Universal binary AND for 32/64bits. This means there are 4 architectures in the binaries.


lantrix@lexx:~ $ file /usr/sbin/httpd
/usr/sbin/httpd: Mach-O fat file with 4 architectures


When I compile PHP as x86_64 of course it complains that the pgsql libs are also not x86_64, and when I compile postgresql as x86_64, it complains the fink readline library I use is not x86_64. Talk about architectural dependancies! I will need to do another post in depth on the fun had with that whole set of dependancies.

This is how and why I arrived at compiling readline on my Mac 64bit intel under Leopard.

On to the readline problems. I start the compile of readline as x86_64 architecture, and this occurs:
gcc -dynamic -arch x86_64 -bind_at_load -arch_only `/usr/bin/arch` -install_name /usr/local/lib/libreadline.5.2.dylib -current_version 5.2 -compatibility_version 5 -v -o libreadline.5.2.dylib readline.so vi_mode.so funmap.so keymaps.so parens.so search.so rltty.so complete.so bind.so isearch.so display.so signals.so util.so kill.so undo.so macro.so input.so callback.so terminal.so text.so nls.so misc.so xmalloc.so history.so histexpand.so histfile.so histsearch.so shell.so mbutil.so tilde.so compat.so -lncurses
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)
i686-apple-darwin9-gcc-4.0.1: -compatibility_version only allowed with -dynamiclib
make[1]: *** [libreadline.5.2.dylib] Error 1
make: [shared] Error 2 (ignored)

Google is your friend, and MacOSXHints forum user dmacks has an answer why this occurs.

The readline compile scripting is ugly (doesn’t use standard build tools, then fakes it…poorly at times). You need -dynamiclib not -dynamic to compile a shared library on OS X, but this indicates a deeper problem: need to patch support/shobj-conf to know darwin9* as a Darwin/MacOS system if you’re on Leopard (I think readline5.2 only recognizes darwin8*, i.e., Tiger).

Still this is not a fix…. But some further searching and I find a Christopher Rasch on a Watir mailing list who shows how to get around this. Effectivly you need to change the makefile for readlines shlibs to use the -dynamiclib switch when compiling.

This gave me a local x86_64 architecure readline library under Leopard. I was able to successfully compile PostgreSQL as -arch x86_64 against the readline library as well.


lantrix@lexx:/usr/local/src/readline-5.2 $ ls -l /usr/local/lib/libreadline.*
-r-xr-xr-x 1 root lantrix 272480 3 Jan 02:06 /usr/local/lib/libreadline.5.2.dylib
lrwxr-xr-x 1 root lantrix 21 3 Jan 02:06 /usr/local/lib/libreadline.5.dylib -> libreadline.5.2.dylib
-rw-r--r-- 1 root lantrix 934864 3 Jan 02:06 /usr/local/lib/libreadline.a
lrwxr-xr-x 1 root lantrix 21 3 Jan 02:06 /usr/local/lib/libreadline.dylib -> libreadline.5.2.dylib


Do what you will with them 🙂