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:
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:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
