|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2009-07-04 00:47 UTC] gwynne@php.net
Description: ------------ This is a reference to PECL bug #16575 <http://pecl.php.net/bugs/bug.php?id=16575>. Since intl will shortly be part of core instead of PECL, I feel this bug belongs here. Here's my addition to the issue: This is due to intl/msgformat/msgformat_helpers.cpp being a C++ file and GCC not handling that case cleanly. The exact error is specifically due to GCC not linking to libstdc++. Which is, actually, kinda reasonable since it's been invoked as a plain C compiler. Anyway, you can get around the problem for now by adding "/usr/lib/gcc/i686-apple-darwin9/4.2.1/libstdc++.dylib" (if you're building with gcc-4.2) or "/usr/lib/gcc/i686-apple-darwin9/4.0.1/libstdc++.dylib" (if you're building with gcc-4.0, the default) to your LDFLAGS. That's right, WITHOUT -l or -L. I wouldn't consider this a real solution, but a better solution is pending further research into the subject. Reproduce code: --------------- $ CFLAGS='-arch x86_64' CXXFLAGS='-arch x86_64' LDFLAGS='-arch x86_64' ./configure --enable-intl --with-icu=/path/to/icu $ make Expected result: ---------------- Build complete. Don't forget to run 'make test'. $ Actual result: -------------- Undefined symbols: "___gxx_personality_v0", referenced from: EH_frame1 in msgformat_helpers.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [sapi/cgi/php-cgi] Error 1 $ PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Sun Dec 22 06:01:30 2024 UTC |
I'm using OSX 10.5 as well and I'm getting the same error when trying to build PHP 5.3.0 with intl enabled. Undefined symbols: "___gxx_personality_v0", referenced from: ___gxx_personality_v0$non_lazy_ptr in msgformat_helpers.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 LDFLAGS="/usr/lib/gcc/i686-apple-darwin9/4.0.1/libstdc++.dylib" export LDFLAGS ./configure \ --disable-all \ --with-libxml-dir=/usr \ --with-apxs2=/usr/local/apache22/bin/apxs \ --with-regex=php \ --with-zend-vm=CALL \ --with-curl=/usr \ --with-curlwrappers \ --with-gd \ --with-gettext=/usr \ --with-iconv \ --with-pear=/usr/local/lib/php \ --with-mysqli=mysqlnd \ --with-pdo-mysql=mysqlnd \ --with-openssl=/usr \ --with-pcre-regex \ --with-zlib-dir=/usr \ --with-xsl=/usr \ --with-jpeg-dir=/usr \ --with-png-dir=/usr \ --with-icu-dir=/usr/local \ --enable-tokenizer \ --enable-ctype \ --enable-mbstring \ --enable-session \ --enable-simplexml \ --enable-xml \ --enable-hash \ --enable-libxml \ --enable-dom \ --enable-filter \ --enable-fileinfo \ --enable-bcmath \ --enable-json \ --enable-intl \ --enable-pdo \ --enable-pcntl \ --enable-shmop \ --enable-phar \ --enable-posix \ --enable-socketstl;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)?This problem is cropping up on CentOS 7 x86_64 with PHP 5.3.29. It looks like the PHP devs resolved this in later versions of PHP by adding PHP_ADD_LIBRARY macros to acinclude.m4 and aclocal.m4. The odd thing is, on CentOS 6.5, the resulting sapi/cli/php binary properly links against libstdc++ even though it isn't passing -lstdc++ to the linker. I'll need to figure out why that's possible at a later date. To resolve this specific issue, I did the following. 1. Patch acinclude.m4 and aclocal.m4 2. re-run ./buildconf This regenerates the configure script and ensures that the -lstdc++ is used to properly link sapi/cli/php. However, it also ensures scripts/php-config is updated with the -lstdc++ library as well. This update ensures all extensions that that are compiled against your PHP version also link against stdc++. The patch: commit 9fc87ffe4384306abb4454ced58b02a79114038e Author: S. Kurt Newman <kurt.newman@cpanel.net> Date: Wed Feb 25 17:45:36 2015 -0600 add stdc++ to acinclude and aclocal for php 5.3.29 diff --git a/acinclude.m4 b/acinclude.m4 index 2681b79..6ad028e 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -762,6 +762,7 @@ AC_DEFUN([PHP_REQUIRE_CXX],[ if test -z "$php_cxx_done"; then AC_PROG_CXX AC_PROG_CXXCPP + PHP_ADD_LIBRARY(stdc++) php_cxx_done=yes fi ]) diff --git a/aclocal.m4 b/aclocal.m4 index 07b5e61..f3770e2 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -762,6 +762,7 @@ AC_DEFUN([PHP_REQUIRE_CXX],[ if test -z "$php_cxx_done"; then AC_PROG_CXX AC_PROG_CXXCPP + PHP_ADD_LIBRARY(stdc++) php_cxx_done=yes fi ])