Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » PHP_SHLIB_SUFFIX not being properly set on MacOSX »

PHP_SHLIB_SUFFIX not being properly set on MacOSX

php.internals

Brad House

21 years ago
Just tried to phpize an extension, and it appears as though there is a problem on MacOSX. PHP_SHLIB_SUFFIX defaults to .so because a check is run on $host_alias, which is set to "". Attached is a patch to use $host_os instead which fixes the problem. This is against php-4.3.10 by the way. I have not confirmed if PHP 5 has this issue or not. -Brad

Jani Taskinen

21 years ago
How exactly did you run the phpize and the generated configure? What are the autoconf, libtool and automake versions in your system? Checking configure generated on my machine, it's impossible for $host_alias to be empty unless you specify it to be empty with --host="" or something like that. I wouldn't want to fix something that really isn't broken. :) --Jani On Tue, 4 Jan 2005, Brad House wrote:

Brad House

21 years ago
brad@laptop ~ $ autoconf --version autoconf (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. brad@laptop ~ $ automake --version automake (GNU automake) 1.9.3 Written by Tom Tromey <tromey@redhat.com>. Copyright 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. brad@laptop ~ $ libtool --version ltmain.sh (GNU libtool) 1.5.10 (1.1220.2.131 2004/09/19 12:46:56) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I just ran phpize which gave no errors, then ./configure make make install make distclean on a Linux box then tarred it up, and sent it to my MacOSX box, and ./configure barfed on an OpenSSL detection because it was looking for libssl.so and libcrypto.so instead of libssl.dylib and libcrypto.dylib. config.log _clearly_ showed that host_alias was blank. -Brad Jani Taskinen wrote:

Andrei Zmievski

21 years ago
On Tue, 04 Jan 2005, Brad House wrote:
> Just tried to phpize an extension, and it appears as though > there is a problem on MacOSX. PHP_SHLIB_SUFFIX defaults to .so > because a check is run on $host_alias, which is set to "".
Just to make sure: we do want PHP_SHLIB_SUFFIX to be set to .so on Mac OS X. Since we are not linking against the extensions, the .dylib does not apply. - Andrei

Brad House

21 years ago
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. -Brad Andrei Zmievski wrote:

Andrei Zmievski

21 years ago
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

Brad House

21 years ago
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:

Andrei Zmievski

21 years ago
On Thu, 06 Jan 2005, Brad House wrote:
> 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.
Yes. The PHP_SHLIB_SUFFIX_NAME macro figures out the actual suffix which gets substituted into main/build-defs.h.in and later defined as a constant in main.c.
> 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.
Yes, I realize that. Which is why I was saying that we should probably use separate constants for build system lib suffix and the extension one. - Andrei

Brad House

21 years ago
ok, so they _are_ different names then: In the auto-scripts it's SHLIB_SUFFIX_NAME as per this that get's pulled in as an actual PHP constant. main/build-defs.h.in:91:#define PHP_SHLIB_SUFFIX "@SHLIB_SUFFIX_NAME@" main/main.c:1206: REGISTER_MAIN_STRINGL_CONSTANT("PHP_SHLIB_SUFFIX", PHP_SHLIB_SUFFIX, sizeof(PHP_SHLIB_SUFFIX)-1, CONST_PERSISTENT | CONST_CS); Even though it is confusing, PHP_SHLIB_SUFFIX is a safe variable to use, and has been being used to denote the extension for shared libraries when looking for dependancies on the OS. And the function that ends up defining SHLIB_SUFFIX_NAME is PHP_SHLIB_SUFFIX_NAME ... so still no conflict ... though it all does get confusing... My patch still needs to be applied, regardless if a naming changes takes place or not, because even with a naming change, $host_alias will not be defined. -Brad Andrei Zmievski wrote:

Jani Taskinen

21 years ago
Yes, they are different things. I committed a bit better fix in CVS now. Remember to run ./cvsclean && ./buildconf after update. $host_alias will not be empty now. If it is, configure will stop at that. --Jani On Thu, 6 Jan 2005, Brad House wrote: