Not a real suggestion, but a comment on this...
There is no reason to use dylib for libraries that will only be loaded by php. the php library itself should be .dylib, by php extensions *can* be .so. Python works this way. However, I'm not convinced it's the best thing, as it does lead to further confusion. Sticking with dylib across the board is much clearer.
The only questionable part is the sapi modules, where it would depend more on what is loading the sapi.
Andrei Zmievski wrote:
I've been trying to build PHP-GTK on OSX and ran into something. The GNU libtool can create shared libraries both with .so and .dylib extensions, depending on whether they are compiled as modules or libraries that can be linked against. If -module is specified for libtool, it'll link an .so library, and this option seems to be configured by default (i.e., I didn't do anything to specifically enable it during buildconf/configure stage). However, we define PHP_SHLIB_SUFFIX to always be .dylib on OSX and the portability of scripts breaks in this case. Any suggestions?
-Andrei
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
