Are you sure we're talking about the same constant here. The one in particular I'm talking about is 100% in the build system. I do not believe it is exported as a define into the actual code... Though I could be wrong.
Having PHP_SHLIB_SUFFIX is confusing though, as MacOSX differentiates shared libraries and modules.
shared libraries have a .dylib extension, while loadable modules have a .so extension, and they are not interchangable :/ Very odd.
-Brad
Andrei Zmievski wrote:
On Thu, 06 Jan 2005, Brad House wrote:
I think you lost me somewhere ....
The module still gets compiled as myext.so PHP_SHLIB_SUFFIX does not affect that at all (perhaps you're saying it's supposed to but did not?)
The PHP_SHLIB_SUFFIX affects the autoconf macro PHP_SETUP_OPENSSL() specifically on MacOSX (it may very well affect others too), because it is searching for libcrypto.so and libssl.so INSTEAD OF libcrypto.dylib and libssl.dylib this is WRONG, as libssl.so and libcrypto.so do NOT exist on MacOSX.
So no, we DO NOT want PHP_SHLIB_SUFFIX to be .so on MacOSX, as it causes detection to fail. If you look at my patch, the correct logic was already in place, I just changed $host_alias to $host_os because $host_alias was not being set, so the check did nothing.
Umm, people are using PHP_SHLIB_SUFFIX in combination with dl() to load standalone extensions. Like this:
dl("php_gtk" . PHP_SHLIB_SUFFIX);
http://www.php.net/dl
It's very common. So, setting it to .dylib is going to break things. Perhaps we should have a different macro/constant for PHP_SETUP_OPENSSL().
- Andrei
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
