mod_perl2 and libapreq2 on Mac OS X Leopard
Wednesday, January 21, 2009 - 12:27 PM
Just to document this somewhere...
However, when you just install them from CPAN, you get the following error from apache:
Cannot load /usr/libexec/apache2/mod_perl.so into server: dlopen(/usr/libexec/apache2/mod_perl.so, 10): no suitable image found. Did find:\n\t/usr/libexec/apache2/mod_perl.so: no matching architecture in universal wrapper
(Once you fix this, you get a similar error for libapreq2:
Cannot load /usr/libexec/apache2/mod_apreq2.so into server: dlopen(/usr/libexec/apache2/mod_apreq2.so, 10): no suitable image found. Did find:\n\t/usr/libexec/apache2/mod_apreq2.so: mach-o, but wrong architecture
Documented here purely for search engine indexing purposes.)
It turns out that the fix is two-fold.
The root cause is that the Mac now supports multiple different chip architectures, to see this, run the
file command on an executable:
$ file /usr/sbin/httpd
/usr/sbin/httpd: Mach-O universal binary with 4 architectures
/usr/sbin/httpd (for architecture ppc7400): Mach-O executable ppc
/usr/sbin/httpd (for architecture ppc64): Mach-O 64-bit executable ppc64
/usr/sbin/httpd (for architecture i386): Mach-O executable i386
/usr/sbin/httpd (for architecture x86_64): Mach-O 64-bit executable x86_64
$ file /usr/bin/perl
/usr/bin/perl: Mach-O universal binary with 2 architectures
/usr/bin/perl (for architecture ppc7400): Mach-O executable ppc
/usr/bin/perl (for architecture i386): Mach-O executable i386
The problem is in mixing architectures, and that cpan (or gcc, or perl, or the default environment, or something), only compiles for the i386 architecture by default. After some googling, I learned that the solution is that you need to "force" cpan to compile the shared libraries for both the i386 and the x86_64 architectures. To do this you need to run:
$ export ARCHFLAGS="-arch i386 -arch x86_64"
$ export CFLAGS="-arch i386 -arch x86_64"
(or add those lines to
~/.profile and open a new terminal window.)
However, after that libapreq2 still fails, which brings me to why I'm writing this. The only link I found with a solution was: http://my.opera.com/ismailp/blog/2008/09/05/svn-web-on-mac-os-x-leopard:
I simply had to hack libapreq2's Makefile.PL and changed following line:
my $cmd = "./configure $opts";
my $cmd = "./configure $opts --disable-dependency-tracking";
Then, clean up my previous attempts, run the make/install process again, and
httpd -t (or
apachectl configtest) suddenly work.
Undoubtedly, DBI or something will break next, but at least it's a start.
Hell, let's face it, we're not responsible for anything; including the things we say, do, or think. And if you sue us because you think we are? Well, we're not responsible for that either.