PECL memcache and PHP on Mac OS X Leopard
May 30, 2009
Wow, has it really been that long since I’ve written here? I really need to do better.
So tonight I ran into an interesting issue this evening in configuring PECL memcache to run on my Macintosh. To give you a bit of background, I use the built-in copy of Apache, but with PHP (current 5.2.8) compiled from source since the version in Leopard is old and I needed some things that it didn’t provice. After that was installed with no problems, I went to the ext/memcache-3.0.4 directory to compile memcache as so:
> phpize
> ./configure
> make
> make install
Then added it to php.ini as an extension and restarted apache. But it didn’t work. The information returned from phpinfo() still indicated it had not been installed. So I checked the logs and found this little gem:
PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib/php/extensions/no-debug-non-zts-20060613/memcache.so’ – (null) in Unknown on line 0
Okay. WTF does that mean? While Googling around for an answer, I came across this page. According to it,it’s a strong indication that you’ve likely compiled against the wrong architecture! This is an indication that the shared extension is causing a segmentation fault. Fortunately, there is a solution – force configure to use the right architecture.
> make clean
> MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS=”-arch x86_64 -g -Os -pipe -no-cpp-precomp” CCFLAGS=”-arch x86_64 -g -Os -pipe” CXXFLAGS=”-arch x86_64 -g -Os -pipe” LDFLAGS=”-arch x86_64 -bind_at_load” ./configure
> make
> make install
Now restart apache. You should have working memcache!
May 31, 2009 at 9:23 pm
[...] PM My coworker Rob ran into an issue building the PECL/memcache extension on his Mac. He did find the solution however. You can read and leave comments on his [...]
May 31, 2009 at 11:54 pm
Why don’t you use macports or finkproject?
Is it really cool to remember all compilation flags, make parameters and other?
June 1, 2009 at 7:25 am
This is a topic I’m also learning about while [recently] compiling PHP as x86_64. For many base libraries (like libxml2) I use Macports which does a decent job dealing with the x86_64 stuff. Many packages offer the x86_64 variant but I typically use +universal (after first adding x86_64 to universal_archs in macports.conf) and it typically works, but not always (yet).
For PECL extensions, the *FLAGS typically works and about a week ago I grew tired and simply added them to .profile
June 1, 2009 at 8:29 am
It really has less to do with being cool and more to do with getting something that works, and doing it quickly.
I tried getting macports to work on my Mac about a year or so ago. It’s an exciting concept; all my Linux systems run Gentoo, so I was excited by the idea of a portage-like environment for Mac. I couldn’t get it to work quite right, but I will grant that I didn’t put a lot of work into it. I was pressed for time and needed working updated PHP. Nonetheless, it took less time for me to download and compile the source by hand than I spent messing with macports.
I may try macports again, but I really don’t have a lot of incentive. There’s about five or six things I need that the mac is missing (ngrep, wget, and a few others), and all can be easily compiled from source, so there’s not a lot of reason for me to mess with it again.
June 1, 2009 at 9:01 am
[...] Peck has figured out a way to get memcache (pecl) to compile on his Mac (OS X). So tonight I ran into an interesting issue [...]
June 1, 2009 at 9:39 am
Macports works nice for base libraries (like libxml2) and does so quickly. And it’s nice to keep them tucked away in a known location (like /opt/local) and know it won’t mess with the Mac itself (e.g., libxml2 has an issue with that). And having other people work on getting everything to compile nicely is a plus, and offers a place to complain to (write a bug report).
In summary: I think it’s useful for some things, but not everything.
June 1, 2009 at 10:13 am
I’m wondering, that you didn’t run into similar problems after compiling the php module itself, because that was it for me: apache2 couldn’t start because it ran in 64bit, while php was in 32bit (some extensions run apparently only in 32bit mode).
A while my solution was to strip the httpd binary with lipo (run “man lipo” in Terminal.app) into a 32bit binary. Now, I let the (fat) apache binary run in 32bit mode, by changing the “ProgramArguments” array in /System/Library/org.apache.httpd.list into:
arch
-i386
/usr/sbin/httpd
-D
FOREGROUND
If you have a better solution, I would be very interested.
June 1, 2009 at 11:32 am
Solution: Compile PHP as 64 bit.
If a certain extension does not allow this, then report a bug (or clarify).
June 4, 2009 at 3:21 am
Mr. Stricker’s solution of using lipo to strip the httpd binary worked for me. Freakin’ 64-bit, man… Coming from a Linux server background, I did a uname -a on my client’s Mac OS server, and figured since it said i386, I wouldn’t even have to worry about 64-bit.