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
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
Just tried to phpize an extension, and it appears as though
there is a problem on MacOSX.PHP_SHLIB_SUFFIXdefaults 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
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:
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. :) --JaniJust tried to phpize an extension, and it appears as though
there is a problem on MacOSX.PHP_SHLIB_SUFFIXdefaults 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
Just tried to phpize an extension, and it appears as though
there is a problem on MacOSX.PHP_SHLIB_SUFFIXdefaults 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
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:
Just tried to phpize an extension, and it appears as though
there is a problem on MacOSX.PHP_SHLIB_SUFFIXdefaults to .so
because a check is run on $host_alias, which is set to "".Just to make sure: we do want
PHP_SHLIB_SUFFIXto be set to .so on Mac
OS X. Since we are not linking against the extensions, the .dylib does
not apply.
- Andrei
I think you lost me somewhere ....
The module still gets compiled as myext.so
PHP_SHLIB_SUFFIXdoes not affect that at all (perhaps
you're saying it's supposed to but did not?)The
PHP_SHLIB_SUFFIXaffects 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_SUFFIXto 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);
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
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:
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_SUFFIXaffects 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_SUFFIXto 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_SUFFIXin combination withdl()to load
standalone extensions. Like this:dl("php_gtk" . PHP_SHLIB_SUFFIX);
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
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_SUFFIXis 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
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:
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_SUFFIXis 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
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
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_SUFFIXis 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:
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_SUFFIXis 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