Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795&edit=1 ID: 48795 Comment by: [email protected] Reported by:[email protected] Summary:Building intl 64-bit fails on OS X Status: Verified Type: Bug Package:Compile Failure Operating System: OS X 10.5 & 10.6; Linux PHP Version:5.3 SVN; 5.4.0RC1 Block user comment: N Private report: N New Comment: Also happens again with PHP 5.3.12 on Ubuntu 12.04 -- stas fix confirmed. A generic solution would be nice, indeed. Previous Comments: [2012-03-13 15:46:33] dan at cdchase dot com It would be helpful if the build system imported any already set CFLAGS. As I've experienced this issue before, so I've set the appropriate CFLAGS in my default environment. But, the automated install routine does not honor these. I have to manually install for them to be honored. [2011-11-14 16:54:00] [email protected] I can confirm Stas's suggestion (s/CC/CXX/ in BUILD_* vars) works with 5.4.0RC1 on linux 64-bit. [2011-11-11 11:30:21] [email protected] tl;dr: Debian Testing and Ubuntu 11.10 have the same problem with ./configure --enable-intl --with-curl. Effectively the same issue (required C++ linkage not occurring) is now happening on Ubuntu 11.10 (x86-64) and Debian Testing (armv7l) with PHP 5.3 SVN and PHP 5.4.0RC1 when compiling with both intl and curl enabled (note that a compile with just --enable-intl succeeds). It's notable that both these distributions feature the new Debian "multiarch" support. Both libcurl and libicu are the normal packaged versions. With ./configure --enable-intl --with-curl, the result of the compile (on the Ubuntu box, although the Debian errors are effectively the same, just with different architecture-specific paths) is this: /usr/bin/ld: ext/intl/msgformat/msgformat_helpers.o: undefined reference to symbol '__gxx_personality_v0@@CXXABI_1.3' /usr/bin/ld: note: '__gxx_personality_v0@@CXXABI_1.3' is defined in DSO /usr/lib/x86_64-linux-gnu/libstdc++.so.6 so try adding it to the linker command line /usr/lib/x86_64-linux-gnu/libstdc++.so.6: could not read symbols: Invalid operation collect2: ld returned 1 exit status make: *** [sapi/cgi/php-cgi] Error 1 Diffing the Makefile produced by --enable-intl alone with the "--enable-intl --with-curl" combination produces the following (excluding rules directly related to compiling objects within ext/curl): @@ -75,9 +76,9 @@ CXXFLAGS_CLEAN = -g -O2 DEBUG_CFLAGS = EXTENSION_DIR = /usr/local/lib/php/extensions/no-debug-non-zts-20100525 -EXTRA_LDFLAGS = -EXTRA_LDFLAGS_PROGRAM = -EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lxml2 -lxml2 -ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2 -lcrypt -lxml2 -lxml2 -lxml2 -lcrypt +EXTRA_LDFLAGS = -L/usr/lib/x86_64-linux-gnu +EXTRA_LDFLAGS_PROGRAM = -L/usr/lib/x86_64-linux-gnu +EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lcurl -lrt -lm -ldl -lnsl -lxml2 -lcurl -lxml2 -ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2 -lcrypt -lxml2 -lxml2 -lxml2 -lcrypt ZEND_EXTRA_LIBS = INCLUDES = -I/tmp/php-5.4.0RC1/ext/date/lib -I/tmp/php-5.4.0RC1/ext/ereg/regex -I/usr/include/libxml2 -I/tmp/php-5.4.0RC1/ext/sqlite3/libsqlite -I$(top_builddir)/TSRM -I$(top_builddir)/Zend EXTRA_INCLUDES = @@ -86,13 +87,13 @@ LFLAGS = LIBTOOL = $(SHELL) $(top_builddir)/libtool --silent --preserve-dup-deps LN_S = ln -s -NATIVE_RPATHS = +NATIVE_RPATHS = -Wl,-rpath,/usr/lib/x86_64-linux-gnu PEAR_INSTALLDIR = ${exec_prefix}/lib/php PHP_BUILD_DATE = 2011-11-11 -PHP_LDFLAGS = +PHP_LDFLAGS = -L/usr/lib/x86_64-linux-gnu PHP_LIBS = OVERALL_TARGET = -PHP_RPATHS = +PHP_RPATHS = -R /usr/lib/x86_64-linux-gnu PHP_SAPI = none PHP_VERSION = 5.4.0RC1 PHP_VERSION_ID = 50400 Stas's suggestion of replacing the $(BUILD_CGI) and $(BUILD_CLI) instances of $(CC) in the generated Makefile with $(CXX) fixes the build. I'm not familiar enough with our build system to know how to fix this, but we should probably do something if we can for 5.4.0 final: intl and curl doesn't seem like it would be an unusual combination. Can we hack the build system to use the C++ compiler preferentially if ext/intl and ext/curl are enabled, if it can't be fixed "properly" (whatever form that takes -- it may even up being an upstream issue)? [2011-11-06 19:11:09] luke at cywh dot com Is there going to be a proper fix for this any time soon? I'm having a lot of trouble getting 5.3.8 to compile on OS X 10.6.8. --
#48509 [NEW]: formatOutput does not work with saveHTML
From: [email protected] Operating system: Mac OS X 10.5.7 PHP version: 5.3CVS-2009-06-09 (CVS) PHP Bug Type: DOM XML related Bug description: formatOutput does not work with saveHTML Description: While writing test cases on Oslo TestFest 2009 I just found that the $dom->formatOutput does not work with $dom->saveHTML() (even though it seems to have been resolved here: http://bugs.php.net/bug.php?id=35673) xmllint says: $ xmllint --format --html output.html http://www.w3.org/TR/REC-html40/loose.dtd";> This is the title so according to Hannes here this seems to be a bug in PHP 5.3 (may be that it's fixed i HEAD but not backported?). Reproduce code: --- formatOutput = true; $root = $doc->createElement('html'); $root = $doc->appendChild($root); $head = $doc->createElement('head'); $head = $root->appendChild($head); $title = $doc->createElement('title'); $title = $head->appendChild($title); $text = $doc->createTextNode('This is the title'); $text = $title->appendChild($text); echo $doc->saveHTML(); ?> Expected result: This is the title Actual result: -- This is the title -- Edit bug report at http://bugs.php.net/?id=48509&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48509&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48509&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48509&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48509&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48509&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48509&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48509&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48509&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48509&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48509&r=support Expected behavior: http://bugs.php.net/fix.php?id=48509&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48509&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48509&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48509&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48509&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48509&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48509&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48509&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48509&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48509&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48509&r=mysqlcfg
#47329 [NEW]: Crash in garbage collector
From: [email protected] Operating system: Linux 2.6.28-gentoo-r1 PHP version: 5.3.0beta1 PHP Bug Type: Scripting Engine problem Bug description: Crash in garbage collector Description: The execution of the test script crashes with: $ php trigger_bug.php /home/kore/local/bin/php/php-5.3-cvs/php-src/Zend/zend_hash.c(668) : ht=0x9842a70 is being destroyed When garbage collector is disabled, the code works as expected (but takes a while): $ php -dzend.enable_gc=0 trigger_bug.php ezcDocumentParserException: Parse error: Fatal error: 'Unexpected node: Title.' in line 2656 at position 1. [...] The error seems to only occur on 32bit systems. Reproduce code: --- The issue only occurs with "big" parsed text documents, so that there is no small reproducing case - a full self contained reproducing case can be found here: http://k023.de/gc_bug.tar.bz2 (155KB). Switch into the directory "gc_bug" and run "php trigger_bug.php". -- Edit bug report at http://bugs.php.net/?id=47329&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47329&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47329&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47329&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47329&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47329&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47329&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47329&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47329&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47329&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47329&r=support Expected behavior: http://bugs.php.net/fix.php?id=47329&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47329&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47329&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47329&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47329&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47329&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47329&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47329&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47329&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47329&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47329&r=mysqlcfg
