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] d...@php.net Did you build any module as shared? ------------------------------------------------------------------------ [2012-12-06 21:41:17] d...@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
