Leopard and iconv
Anyone who uses Leopard's PHP realises pretty quickly that the binary is lacking some very basic modules, not the least of which is MySQL. Why provide MySQL, PHP, and a *nix platform and not put MySQL as a module into the PHP object? Don't try to answer this question - there is no answer. Put it down to Apple cuteness I guess.
If you're PHPing on a Mac, your also probably recompiling your PHP object regularly, to pick up modules your latest pet needs. Chief among these as mentioned before would be MySQL, but gettext, curl, crypto and SSL would be up there too.
Compiling these monster binaries on a Mac is not quite the *nix goodness one would hope for given the Darwin foundation - google around and you'll find a top 3 or so problems list that if nothing else, shows you that other people round the world are tearing their hair out too!
My biggest problem always seems to be iconv. It seems Apple's version does/does not (?) include the functions lib_iconvopen and libiconv_close (or at least the .h files don't redefine the functions). Simple you might think: get a new iconv that works, compile it into /usr/local and away you go. Wrong. You'll probably get a scrambled message telling you iconv functions ain't found or don't work.
I always forget how I get out of this quagmire, so here I am documenting it here so I won't lose it, and you might find it helpful!
::::::: AT THE LAST COMPILATION STEP WHERE libphp5.so IS CREATED, MANUALLY ORDER YOUR -L/libs and I/includes ARGUMENTS SO THE COMPILER PICKS UP CONSISTENT HEADER AND LIBRARIES GIVEN YOUR NEW MODULE BINARIES::::
By the time the PHP make gets to this step, there are duplicated -l's -L's and -I's all over the place. Unfortunately, -L/usr/lib can come up first - making all the work you did compiling new add in modules useless. Simple eh? Yet it's amazing how many postings on various fora are out there still wondering how to deal with this nasty, but basic little problem. So...don't rely 100% on the output of ./configure - some handcrafting will get you to the Khubla Khan of 64-bit PHP your way.
If you're PHPing on a Mac, your also probably recompiling your PHP object regularly, to pick up modules your latest pet needs. Chief among these as mentioned before would be MySQL, but gettext, curl, crypto and SSL would be up there too.
Compiling these monster binaries on a Mac is not quite the *nix goodness one would hope for given the Darwin foundation - google around and you'll find a top 3 or so problems list that if nothing else, shows you that other people round the world are tearing their hair out too!
My biggest problem always seems to be iconv. It seems Apple's version does/does not (?) include the functions lib_iconvopen and libiconv_close (or at least the .h files don't redefine the functions). Simple you might think: get a new iconv that works, compile it into /usr/local and away you go. Wrong. You'll probably get a scrambled message telling you iconv functions ain't found or don't work.
I always forget how I get out of this quagmire, so here I am documenting it here so I won't lose it, and you might find it helpful!
::::::: AT THE LAST COMPILATION STEP WHERE libphp5.so IS CREATED, MANUALLY ORDER YOUR -L/libs and I/includes ARGUMENTS SO THE COMPILER PICKS UP CONSISTENT HEADER AND LIBRARIES GIVEN YOUR NEW MODULE BINARIES::::
By the time the PHP make gets to this step, there are duplicated -l's -L's and -I's all over the place. Unfortunately, -L/usr/lib can come up first - making all the work you did compiling new add in modules useless. Simple eh? Yet it's amazing how many postings on various fora are out there still wondering how to deal with this nasty, but basic little problem. So...don't rely 100% on the output of ./configure - some handcrafting will get you to the Khubla Khan of 64-bit PHP your way.
Comments
Post a Comment