|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #48795 Building intl 64-bit fails on OS X
Submitted: 2009-07-04 00:47 UTC Modified: 2018-06-24 04:22 UTC
Avg. Score:4.4 ± 0.9
Reproduced:36 of 36 (100.0%)
Same Version:20 (55.6%)
Same OS:20 (55.6%)
From: Assigned: cmb (profile)
Status: No Feedback Package: Compile Failure
PHP Version: 5.3 SVN; 5.4.0RC1 OS: OS X 10.5 & 10.6; Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
26 + 31 = ?
Subscribe to this entry?

 [2009-07-04 00:47 UTC]
This is a reference to PECL bug #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


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-07-16 20:09 UTC] jplock at gmail dot com
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

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 \
 [2009-09-15 15:25 UTC]
I'm having the same exact problem using --enable-intl --with-icu-dir=/path/to/icu

I installed ICU with macports, and so I'm using /opt/local as my path to ICU.
 [2009-11-23 21:58 UTC]
Please try using this snapshot:
For Windows:

 [2009-11-24 01:23 UTC]
No, upgrading the bundled libtool didn't fix it. The buildsystem isn't set up to deal with C++ files automatically.
 [2009-11-24 11:46 UTC]
well, build system does handle C++ quite fine for me. OSX is "special"..
 [2010-01-10 11:54 UTC] harald dot lapp at gmail dot com
same problem here: osx 10.5.8, php5.3-latest

any ideas how to fix this issue?
 [2010-02-10 14:05 UTC] surfchen at gmail dot com
It is a linking problem, here is the simple workaround:
edit Makefile and add -lstdc++ into EXTRA_LIBS.
 [2010-04-20 19:31 UTC] fsb at thefeb dot org
i confirm the fix [2010-02-10 12:05 UTC] surfchen at gmail dot com: "add -lstdc++ into EXTRA_LIBS" worked for 5.3.2 release on osx 10.6.3.
 [2010-05-24 21:19 UTC]
Also if you change $(CC) to $(CXX) in BUILD_* vars in Makefile it seems to help too. Looks like if you use C++ anywhere in PHP the linker should be C++ or library should be added manually. I'll try to see if I can maybe make configure add needed magic juice there...
 [2010-06-17 19:43 UTC] henrik at bearwoods dot dk
I have tried the above "quick-fixes" and have not been able to compile it yet. Im on a Macbook Pro i5 and 10.6.4 (Maybe the i5 makes a difference)
 [2011-07-01 16:23 UTC] harald dot lapp at gmail dot com
just setting the EXTRA_LIBS did not work for me, but stas tip made it work. (PHP 
5.3.6, Mac OS X 10.6.7), thanks!
 [2011-11-06 19:11 UTC] 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.
 [2011-11-11 11:30 UTC]
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

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/ so try adding it to the linker command line
/usr/lib/x86_64-linux-gnu/ 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

@@ -75,9 +76,9 @@
 EXTENSION_DIR = /usr/local/lib/php/extensions/no-debug-non-zts-20100525
-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
 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
@@ -86,13 +87,13 @@
 LIBTOOL = $(SHELL) $(top_builddir)/libtool --silent --preserve-dup-deps
 LN_S = ln -s
+NATIVE_RPATHS = -Wl,-rpath,/usr/lib/x86_64-linux-gnu
 PEAR_INSTALLDIR = ${exec_prefix}/lib/php
 PHP_BUILD_DATE = 2011-11-11
+PHP_LDFLAGS = -L/usr/lib/x86_64-linux-gnu
+PHP_RPATHS = -R /usr/lib/x86_64-linux-gnu
 PHP_SAPI = none

Stas's suggestion of replacing the $(BUILD_CGI) and $(BUILD_CLI)
instances of $(CC) in the generated Makefile with $(CXX) fixes the

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-11 11:30 UTC]
-Operating System: Mac OS X 10.5.8, 10.6.2 +Operating System: OS X 10.5 & 10.6; Linux -PHP Version: 5.3SVN-2009-11-23 (SVN) +PHP Version: 5.3 SVN; 5.4.0RC1
 [2011-11-14 16:54 UTC]
I can confirm Stas's suggestion (s/CC/CXX/ in BUILD_* vars) works with 5.4.0RC1 
on linux 64-bit.
 [2012-03-13 15:46 UTC] 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.
 [2012-05-08 13:11 UTC]
Also happens again with PHP 5.3.12 on Ubuntu 12.04 -- stas fix confirmed. A generic solution would be nice, indeed.
 [2012-09-11 16:27 UTC]
Same for me, I can't compile either. hope there is a solution
 [2012-10-26 02:59 UTC] pgarvin76 at gmail dot com
This is still and issue on 5.3.18, but 5.4.8 built without error. Interestingly if you build intl as shared you don't get the compile error (how I am currently getting around issue). I am on Ubuntu 12.04.
 [2013-03-08 16:27 UTC] saltwaterc at gmail dot com
sed -i '/EXTRA_LIBS = /s|$| -lstdc++|' Makefile

One liner fix for those who still do (scripted) builds on 5.3.x.
5.3.22 still fails on Ubuntu 12.04.
 [2013-03-09 10:12 UTC] cornelius dot howl at gmail dot com
Quick fix for this 5.3.28 should work

edit Makefile and found the rule of


change the $(CC) to $(CXX)

then run:

sed -i '/EXTRA_LIBS = /s|$| -lstdc++|' Makefile
 [2013-03-09 10:14 UTC] cornelius dot howl at gmail dot com
For this issue, here is the patch in phpbrew
 [2013-06-11 14:10 UTC]
Still happens on 5.3.26. cornelius dot howl at gmail dot com's commands do not help here.
 [2015-02-26 01:17 UTC] kurt dot newman at cpanel dot net
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 <>
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
+    PHP_ADD_LIBRARY(stdc++)
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
+    PHP_ADD_LIBRARY(stdc++)
 [2018-04-09 22:00 UTC]
-Status: Verified +Status: Feedback -Assigned To: +Assigned To: cmb
 [2018-04-09 22:00 UTC]
Is this still an issue with actively supported PHP versions[1]?

[1] <>
 [2018-06-24 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 11:01:30 2024 UTC