Edit report at https://bugs.php.net/bug.php?id=62692&edit=1
ID: 62692
Comment by: eugene at zhegan dot in
Reported by: eugene at zhegan dot in
Summary: PHP fails to build with dtrace
Status: Verified
Type: Bug
Package: *General Issues
Operating System: Solaris 10 x86
PHP Version: 5.4.5
Assigned To: dsp
Block user comment: N
Private report: N
New Comment:
Wow, terribly sorry for misinterpreting the question.
Yup, I've built most of the modules as shared:
xmlrpc,pear,mcrypt,openssl,curl,bz2,xsl,imap,imap-ssl - these are shared modules.
Previous Comments:
------------------------------------------------------------------------
[2012-12-12 17:19:51] eugene at zhegan dot in
Actually the DTrace support for 5.4.x is pretty much working, and one of my long comments here
describes why's it's not building clearly and how to fix it, I suppose the Makefile can be
fixed too (so it doesn't clobber ther dtrace.d file, invokes sed on solaris properly, and most
of all - copies the dtraced object files to .libs). So I hope it's worth fixing.
------------------------------------------------------------------------
[2012-12-12 17:13:26] eugene at zhegan dot in
For 5.3.x - yes (it's not functional though, it loads but no probes are available). For 5.4.x -
nope, I though that since there's an option to actually build PHP with DTRace, there's no
need to build a PECL extension (which wasn't working for me in 5.3.x, I filled a bug and even
tried to reach the authors via e-mail, so why bother).
------------------------------------------------------------------------
[2012-12-06 21:41:30] dsp@php.net
Did you build any module as shared?
------------------------------------------------------------------------
[2012-12-06 21:41:17] dsp@php.net
This bug is about the dtrace probes in core not the PECL package.
------------------------------------------------------------------------
[2012-09-14 15:46:48] eugene at zhegan dot in
Okay. Here are a bit more detailed instruction about how to actually and successfully build php with
dtrace on Solaris. On Solaris Solaris, not on a dead body of Opensolaris or on shiny and rare
Openindiana.
- Run configure with --enable-dtrace.
- You will probably need to use bundled gd, not system or installed from source, so use --with-gd,
whithout a directory.
- It should work fine (actually, there are plenty of ways for it to fail depending on the various
options, but let's assume you know how to build php on Solaris from sources and you're
trying to build it with dtrace for now).
- Now you need to patch the Makefile the configure just created for you. Why ? Because Solaris sed
doesn't have an -i switch. You can patch the Makefile as described here: https://bugs.php.net/bug.php?id=62691 or you can
just install the GNU sed and make it appear in the PATH before the system sed.
- Now you can actually start building php, but read first this: https://bugs.php.net/bug.php?id=61268 . I'll
make it easier: due to the fact that building will crash (see below) twice (see below :) ) you will
need to prevent the zend_dtrace.d probe file from clobbering, due to the nature of gmake and some
issues in the Makefile. :) This is done by using the '-r' switch, which prevents the make
builtin rules from firing.
- Use gmake, it will make your life even more easier.
- Thus, you can run 'gmake -r' now and wait for it to crash.
- It will crash somewhere around making pfp-fpm (if you ordered this sapi) and the crash lines
won't be similar the initial error in this report. The crash lines from the start of this
report are caused by some clobbering and not using 'gmake -r'. You should see a crash like
this:
Undefined first referenced
symbol in file
__dtraceenabled_php___execute__entry Zend/.libs/zend_dtrace.o
__dtraceenabled_php___execute__return Zend/.libs/zend_dtrace.o
__dtrace_php___compile__file__return Zend/.libs/zend_dtrace.o
__dtrace_php___exception__thrown Zend/.libs/zend_exceptions.o
__dtrace_php___error Zend/.libs/zend.o
__dtrace_php___function__entry Zend/.libs/zend_dtrace.o
__dtrace_php___function__return Zend/.libs/zend_dtrace.o
__dtrace_php___request__shutdown main/.libs/main.o
__dtrace_php___exception__caught Zend/.libs/zend_execute.o
__dtrace_php___execute__return Zend/.libs/zend_dtrace.o
__dtrace_php___request__startup main/.libs/main.o
__dtraceenabled_php___exception__caught Zend/.libs/zend_execute.o
__dtrace_php___compile__file__entry Zend/.libs/zend_dtrace.o
__dtraceenabled_php___function__entry Zend/.libs/zend_dtrace.o
__dtrace_php___execute__entry Zend/.libs/zend_dtrace.o
__dtraceenabled_php___error Zend/.libs/zend.o
__dtraceenabled_php___function__return Zend/.libs/zend_dtrace.o
$dtrace18058.ZEND_CATCH_SPEC_CONST_CV_HANDLER Zend/zend_dtrace.d.o
__dtraceenabled_php___exception__thrown Zend/.libs/zend_exceptions.o
ld: fatal: Symbol referencing errors. No output written to sapi/cli/php
collect2: ld returned 1 exit status
gmake: *** [sapi/cli/php] Error 1
- lets discuss what is it and how to fix it. Somewhere over 9000 lines above the building process
made this:
dtrace -G -o Zend/zend_dtrace.d.o -s /home/emz/src/php-5.4.5/Zend/zend_dtrace.d main/main.o
Zend/zend_API.o Zend/zend_execute.o Zend/zend_exceptions.o Zend/zend_dtrace.o Zend/zend.o
What is this ? This is the creation of the ELF binary with dtrace probes AND updating of the source
object files. This is important. But these source object files at this point are already copied in
the .libs directory, which linker is using at the final stage and where it does crash. They should
be updated after running dtrace -G but they are not. In order to fix the building you should do it
by hand:
- copy the files:
Zend/zend_API.o
Zend/zend_execute.o
Zend/zend_exceptions.o
Zend/zend_dtrace.o
Zend/zend.o
to the Zend/.libs
- copy the file
main/main.o
to the main/.libs. They should differ by the way fromthe targets you have in .libs.
- issue a 'gmake -r' in the top php source directory so the building will continue.
Important: issuing just 'gmake' will clobber the Zend_dtrace.d file and you will lose it.
- it will crash again. with something like:
[...]
fpm_sockets.h:28: error: syntax error before numeric constant
- ZOMG again ? why is this ? This is because some bright guys made a variable in the modern part of
the php code named 'sun'. It's in the fpm_sockets.c and .h files:
int fpm_socket_unix_test_connect(struct sockaddr_un *sun, size_t socklen)
- obviously, this name is already used and bind to a constant somewhere is Solaris Solaris (not in
the Opensolaris, not in the Openindiana). o'rly ?
- change all the occurences of this variable in the fpm_sockets.c and fpm_sockets.h to some other
name (I used 'sunn'). Be careful, change only the variables 'sun', not all the
occurences of the 'sun*' (you will encounter 'sun_*' and other stuff, don't
touch it).
- gmake -r. This time it should finish the build.
- to be really honest, I wrote all of this for myself, so I won't lose 4 hours next time I will
need to build php + dtrace on Solaris.
- however, I will be glad if this will save some time for someone.
- yup, I build it with gcc 3.x.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=62692
--
Edit this bug report at https://bugs.php.net/bug.php?id=62692&edit=1