Okay, let me try to be explicit here. If I am leaving out any important
information, please just ask.
Environment:
OS X
uname -a:
Darwin host-29.dev.office.nexopia.com 9.2.2 Darwin Kernel Version 9.2.2:
Tue Mar 4 21:17:34 PST 2008; root:xnu-1228.4.31~1/RELEASE_I386 i386
with php-5.2.5.
What I want:
A php library that can be linked in to another executable (a
custom-written executable, described briefly below) via -lphp5
command-line flag on OS X.
Why the FastCGI option isn't appropriate for us:
We are trying to transition from Php to Ruby and want a way to call Php
code from inside of Ruby. To do this, we have a custom-written
executable "wrapper" to directly call Php.
What I expect will cause this to happen:
./configure --enable-embed --prefix=/nexopia/packages/Php
(or --enable-embed=shared)
This is exactly the configuration flags we use.
What actually happens:
This works on Linux, Windows. On OS X, this configuration fails, as
described in the bug report, 44462.
What happens with the patch I included:
Using ./configure --enable-embed=dylib --prefix=/nexopia/packages/Php
results in a successful build. The resulting libphp5.dylib allows us to
build the other executable and use -lphp5 to link in the Php lib.
What I THINK would happen with a .so instead of .dylib:
Would not be able to link our executable using -lphp5 on OS X.
Again, if I have missed out any useful information, please let me know.
I'm not deliberately hiding anything.
BuildSmart wrote:
On Apr 30, 2008, at 11:20 AM, Christopher Thompson wrote:
I don't want libphp.so as we are not using Apache.
The brief details are roughly as follows:
- we use lighthttpd for a web server
I have lighttpd running in OSX with PHP with quite a few extensions as
well so it's either your configure flags, environment or both that are
causing you problems.
- much of our site is in Php
- we are transitioning to Ruby
- we have a custom-written wrapper to allow Php to run inside of Ruby,
to make the transition a little easier
Without knowing anything about your wrapper I can't comment on it's
effectiveness or implementation but using the correct configure flags
I'm able to generate a shared library of php without your patch so it
has to be somehting your not doing or doing wrong.
You could have saved a lot of grief by posting your complete configure
flag and details about your method of use
Now, this wrapper needs to link to php. On Windows and Linux, that's
easy. But on OS X, if we end up with libphp5.so, the link step fails.
With a dylib, though, the link step succeeds and life is good, if a
little bit rainy.
It is very possible that we actually want a static build. I'm new at
nexopia and previous people who had tried this reported some problems,
though this could have been on an unrelated matter. On the other
hand, ../configure --enable-embed=shared (or just --enable-embed)
fails during the linking step as documented by the bug I linked to, 44462.
I freely admit to not being totally up to speed on OS X build
environments. Until last week, I just sort of assumed OS X used .so
files for everything. In other words, the problem here may be my
expectations, and I would love to be educated on this matter. Still,
the patch I've attached, generating a dylib, does solve the specific
problem I'm trying to solve.
Your patch doesn't give you the results your expecting.
While I was expecting "auto" tools to take care of the shared library
issue, php-5.2.5 still seems to attempt to build an .so file on OS X,
fails (with --enable-embed), and regardless, _I_ suspect should be
generating a dylib for me anyway.
Becuase you provide no details on how any of the software you are using
was built I can only assume what you are trying to achieve is blurred by
your lack of knowledge and understanding of achieving what you require.
Try using "--enable-fastcgi" instead of "--enable-embed" for lighttpd
and also examine the help in configure, you will find that some flags
conflict, while it may work in a particular OS this doesn't make it right.
Then rename php to php-fastcgi, copy php.ini to /etc/lighttpd-php.ini.
Assuming you used "--prefix= /usr/local/php" for php, put the following
in lighttpd.conf you put:
#### fastcgi module
## read fastcgi.txt for more info
fastcgi.server = (".php" =>
(
( "socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/local/php/bin/php-fastcgi -c /etc/lighttpd-php.ini",
"min-procs" => 1,
"max-procs" => 4,
"max-load-per-proc" => 4,
"idle-timeout" => 20
)
)
)
You can take a quick peek at http://daleenterprise.com:86/info.php ,
I'll leave it up for a couple of days.
BuildSmart wrote:
This is taken care of by "auto" tools.
If you are experiencing build issues of public releases then you're
doing something wrong.
I build PHP for a living in OS X and I've encountered no build issues
what-so-ever related to building with dylib linking but the resulting
binary will (should) still be libphp.so because apache expects this.
If you need some help I can spare a few moments and examine your
build environment and offer you some pointers/advice that should help
you to develop better binary builds.
Out of curiosity, why are you enabling embedded in this manner, there
are very few reason that PHP needs to be built this way and the
environment and dependancies need to be established for the build to
be successful.
When building for embedding purposes you really want a static build
(libphp.a rather than libphp.so) so I'm having a hard time
understanding what exactly it is you're trying to achieve.
-- Dale
On Apr 29, 2008, at 19:14 PM, Christopher Thompson wrote:
Please be gentle, I have very little experience developing on OS X.
To be honest, the whole dylib thing seems messy and confusing to me,
compared to the fairly straight-forward Linux style .so approach.
Expected behavior:
Able to configure and build on OS X with:
./configure --enable-embed
Actual behavior:
http://bugs.php.net/bug.php?id=44462
Suspected problem:
Trying to build .so instead of .dylib on OS X.
Suggested solution:
See patch below. This makes it possible to do:
./configure --enable-embed=dylib
I did this instead of fixing --enable-embed=shared because the build
process appears to be fundamentally different.
NOTE! Once applying the patch, you need to do:
aclocal
autoconf
./configure --enable-embed=dylib
If you don't do aclocal to regenerate the necessary files, things break.
diff -urN php-5.2.5.clean/Makefile.global php-5.2.5/Makefile.global
--- php-5.2.5.clean/Makefile.global 2007-08-03 08:01:56.000000000 -0600
+++ php-5.2.5/Makefile.global 2008-04-29 16:44:36.000000000 -0600
@@ -17,6 +17,10 @@
$(LIBTOOL) --mode=link $(CC) $(CFLAGS) $(EXTRA_CFLAGS) -rpath
$(phptempdir) $(EXTRA_LDFLAGS) $(LDFLAGS) $(PHP_RPATHS)
$(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS)
-o $@
[EMAIL PROTECTED](LIBTOOL) --silent --mode=install cp $@ $(phptempdir)/$@
>/dev/null 2>&1
+libphp$(PHP_MAJOR_VERSION).dylib: $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS)
+ $(LIBTOOL) --mode=link $(CC) -dynamiclib -install_name
$(INSTALL_ROOT)$(prefix)/lib/$@ -current_version $(PHP_VERSION)
-compatibility_version $(PHP_MAJOR_VERSION) -undefined
dynamic_lookup $(PHP_RPATHS) $(PHP_GLOBAL_OBJS:.lo=.o)
$(PHP_SAPI_OBJS:.lo=.o) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $@
+ [EMAIL PROTECTED](LIBTOOL) --silent --mode=install cp $@ $(phptempdir)/$@
>/dev/null 2>&1
+
libs/libphp$(PHP_MAJOR_VERSION).bundle: $(PHP_GLOBAL_OBJS)
$(PHP_SAPI_OBJS)
$(CC) $(MH_BUNDLE_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS)
$(LDFLAGS) $(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS:.lo=.o)
$(PHP_SAPI_OBJS:.lo=.o) $(PHP_FRAMEWORKS) $(EXTRA_LIBS)
$(ZEND_EXTRA_LIBS) -o $@ && cp $@ libs/libphp$(PHP_MAJOR_VERSION).so
diff -urN php-5.2.5.clean/acinclude.m4 php-5.2.5/acinclude.m4
--- php-5.2.5.clean/acinclude.m4 2007-08-20 08:28:45.000000000 -0600
+++ php-5.2.5/acinclude.m4 2008-04-29 16:44:44.000000000 -0600
@@ -799,6 +799,15 @@
])
dnl
+dnl PHP_BUILD_DYLIB
+dnl
+AC_DEFUN([PHP_BUILD_DYLIB],[
+ PHP_BUILD_PROGRAM
+ OVERALL_TARGET=libphp[]$PHP_MAJOR_VERSION[.dylib]
+ php_build_target=static
+])
+
+dnl
dnl PHP_BUILD_BUNDLE
dnl
AC_DEFUN([PHP_BUILD_BUNDLE],[
@@ -885,6 +894,7 @@
case "$2" in
static[)] PHP_BUILD_STATIC;;
shared[)] PHP_BUILD_SHARED;;
+ dylib[)] PHP_BUILD_DYLIB;;
bundle[)] PHP_BUILD_BUNDLE;;
program[)] PHP_BUILD_PROGRAM($5);;
esac
diff -urN php-5.2.5.clean/configure.in php-5.2.5/configure.in
--- php-5.2.5.clean/configure.in 2007-11-08 07:44:11.000000000 -0600
+++ php-5.2.5/configure.in 2008-04-29 16:44:52.000000000 -0600
@@ -252,6 +252,7 @@
dnl paths to the targets are relative to the build directory
SAPI_SHARED=libs/libphp[]$PHP_MAJOR_VERSION[.]$SHLIB_DL_SUFFIX_NAME
SAPI_STATIC=libs/libphp[]$PHP_MAJOR_VERSION[.a]
+SAPI_DYLIB=libs/libphp[]$PHP_MAJOR_VERSION[.]$SHLIB_SUFFIX_NAME
SAPI_LIBTOOL=libphp[]$PHP_MAJOR_VERSION[.la]
PHP_CONFIGURE_PART(Configuring SAPI modules)
diff -urN php-5.2.5.clean/sapi/embed/config.m4
php-5.2.5/sapi/embed/config.m4
--- php-5.2.5.clean/sapi/embed/config.m4 2007-07-11
17:20:36.000000000 -0600
+++ php-5.2.5/sapi/embed/config.m4 2008-04-29 16:45:06.000000000 -0600
@@ -4,7 +4,7 @@
PHP_ARG_ENABLE(embed,,
[ --enable-embed[=TYPE] EXPERIMENTAL: Enable building of
embedded SAPI library
- TYPE is either 'shared' or 'static'.
[TYPE=shared]], no, no)
+ TYPE is 'shared', 'static', or 'dylib'.
[TYPE=shared]], no, no)
AC_MSG_CHECKING([for embedded SAPI library support])
@@ -18,6 +18,10 @@
PHP_EMBED_TYPE=static
INSTALL_IT="\$(mkinstalldirs) \$(INSTALL_ROOT)\$(prefix)/lib;
\$(INSTALL) -m 0644 $SAPI_STATIC \$(INSTALL_ROOT)\$(prefix)/lib"
;;
+ dylib)
+ PHP_EMBED_TYPE=dylib
+ INSTALL_IT="\$(mkinstalldirs) \$(INSTALL_ROOT)\$(prefix)/lib;
\$(INSTALL) -m 0644 $SAPI_DYLIB \$(INSTALL_ROOT)\$(prefix)/lib"
+ ;;
*)
PHP_EMBED_TYPE=no
;;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-- Dale
-- Dale
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
