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
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 definePHP_SHLIB_SUFFIXto always be .dylib on OSX
and the portability of scripts breaks in this case. Any suggestions?-Andrei
Sticking with .dylib across the board is fine with me, but try telling
that to libtool. For some reason it wants to stick to .so extension,
instead of .dylib and I just do not have the time or effort to debug
the beast that is libtool. Any hints on how to make it use .dylib?
-Andrei
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.
I guess I'm stepping in, in the middle of the conversation,
but dylibs and so's are totally different on MacOSX.
One of those OS X MACH-O oddities.
.dylib's are libraries which you link against, and are loaded at
runtime. (Shared Library)
.so's are something you can dlopen() (as of 10.3, don't remember
the 10.2 similar functions)... (Loadable Module)
Please note that these are not interchangeable. You cannot
link against a .so, and you cannot dlopen() a .dylib on MacOSX.
If you decide to name all libraries .dylib, even those that are
meant to be dynamically loaded via dlopen, you will add a lot
of confusion into the mix... which is why libtool is most likely
not cooperating.
A good reference on this is here:
http://fink.sourceforge.net/doc/porting/shared.php?phpLang=en#lib-and-mod
-Brad
Andrei Zmievski wrote:
Sticking with .dylib across the board is fine with me, but try telling
that to libtool. For some reason it wants to stick to .so extension,
instead of .dylib and I just do not have the time or effort to debug the
beast that is libtool. Any hints on how to make it use .dylib?-Andrei
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.