Lot of time has passed since i released a stable version of mod_bw.
Stable as it is, it isn’t free of problems.
Frederik Temmermans contacted me a couple of weeks ago, and sent some errors he got compiling current version of mod_bw (0.8 as of now).
He was running MacOSX 10.5.7 with standar Apache 2.2.11.
When compiling normally using apxs, the module will be built and installed. But after starting apache, an error will appear :
httpd.conf: Cannot load /usr/libexec/apache2/mod_bw.so into server:2.dlopen(/usr/libexec/apache2/mod_bw.so, 10): no suitable image found. Did find:/usr/libexec/apache2/mod_bw.so: mach-o, but wrong architecture
So…. There is a binary.. but for the wrong architecture.
As Mac’s nowadays are Intel based, to me it looks like it is a 32/64bits issue.
As MacOSX is a hybrid system running 32 and 64bits apps (since some time), looks like apache is a 64bit application :
# httpd -V
Server version: Apache/2.2.11 (Unix)
Server built: Feb 3 2009 01:54:45
Server's Module Magic Number: 20051115:21
Server loaded: APR 1.2.7, APR-Util 1.2.7
Compiled using: APR 1.2.7, APR-Util 1.2.7
Server MPM: Prefork
forked: yes(variable process count)
# uname -a
Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT14.2009; root:xnu-1228.12.14~1/RELEASE_I386 i386
And it also seems that apxs is compiling a 32bit binary.
(This was my Asus G1 laptop running OSX. Sorry Apple, I know i should not do this.. but it was a quick test to help. If anyone wants to donate a MacBookPro…. :X)
Well, after realizing the issue, it was just a matter of adjusting some compiling flags..
Run apxs like this :
apxs -c -i -Wc,'-arch x86_64' -Wl,'-arch x86_64' mod_bw.c
And that’s it. You’ll have a 64bit module.
Did i said that’s it ?
Well.. Life is not an easy ride. After fixing this, Frederik had another issue. (I find this weird… i had a system setup to be similar to his, and i didn’t have this problem.)
If loading the module you get an error like this one :
httpd: Syntax error on line 117 of /private/etc/apache2/httpd.conf:
Cannot load /usr/libexec/apache2/mod_bw.so into server:
dlopen(/usr/libexec/apache2/mod_bw.so, 10): Symbol not found: _apr_atomic_add\n Referenced from: /usr/libexec/apache2/mod_bw.so
Expected in: dynamic lookup
It is because that symbol (used in the module) is not in your current APR Lib version. I have seen this occur in some linux distros (but never happened to me… damn). When i first received an email regarding this bug, we came up with an easy fix, and it seemed to solve it.
You need to locate and erase this lines from mod_bw.c
#if (APR_MAJOR_VERSION < 1)
#define apr_atomic_inc32 apr_atomic_inc
#define apr_atomic_dec32 apr_atomic_dec
#define apr_atomic_add32 apr_atomic_add
#define apr_atomic_cas32 apr_atomic_cas
#define apr_atomic_set32 apr_atomic_set
Compile again, and that’s it. (this time for real).
In newer releases this should not be an issue anymore. (knock on wood)