RSS
 

PECL memcache and PHP on Mac OS X Leopard

30 May

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!

 
11 Comments

Posted in Apache, Apple, PHP

 

  • Pingback: Building PECL/memcache on Mac OS X

  • http://endeveit.net Endeveit

    Why don’t you use macports or finkproject?
    Is it really cool to remember all compilation flags, make parameters and other?

  • http://blog.roshambo.org/ Philip Olson

    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 :)

  • codelemur

    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.

  • Pingback: Rob Peck’s Blog: PECL memcache and PHP on Mac OS X Leopard | Webs Developer

  • http://blog.roshambo.org/ Philip Olson

    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.

  • http://strickr.de Martin Stricker

    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.

  • http://blog.roshambo.org/ Philip Olson

    Solution: Compile PHP as 64 bit. :) If a certain extension does not allow this, then report a bug (or clarify).

  • http://www.digitalresonator.com Daniel Brown

    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.

  • http://spaceweb.nl Bart McLeod

    You absolutely saved my day! I come from a windows background, but I like Mac and Linux better in many respects, I use all three of them currently. I am not good at things that involve make and configure and phpize. To be honest, I have allways been to lazy to read up on what they are about. No, in fact, I haven’t been to lazy, but whenever I read about these, the text is so geeky, I can’t realy get through. But you really make the difference here!

    I reproduced the steps in your post exactly, even the simple steps and verified that I got a similar log entry. However, my log entry was different: the startup error said the image (probably meaning memcache.so) could not be found.

    Instead of thinking about that I then tried your more complicated steps by just copy pasting them. These produced a lot more output on the screen, but there may be some verbosity switches in there that cause this behavior. Anyway, it looked very promising because it appeared to be building memcache successfuly.

    However, I still got the same startup error. Then I realized I had built the extension in a directory that could not be found because it wasn’t the extension_dir.

    So my last step was to copy memcache to the extension_dir and then restart MAMP and it worked!!!

    Again, thank you very much.

    The only thing I doubt now is if I needed the complicated steps involving the target architecture at all, since the problem seemed to be the wrong location of the built file…

  • http://www.robpeck.com Rob Peck

    Glad I could help!

    I was having target arch issues when I wrote that, but that was like two years ago and I’m pretty sure Macs don’t even ship with any kind of ppc support these days. It may not even be relevant anymore.