Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795edit=1 ID: 48795 Comment by: cwei...@php.net Reported by:gwy...@php.net 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: Still happens on 5.3.26. cornelius dot howl at gmail dot com's commands do not help here. Previous Comments: [2013-03-09 10:14:47] cornelius dot howl at gmail dot com For this issue, here is the patch in phpbrew https://github.com/c9s/phpbrew/commit/18ef766d0e013ee87ac7d86e338ebec89fbeb445 [2013-03-09 10:12:31] cornelius dot howl at gmail dot com Quick fix for this 5.3.28 should work edit Makefile and found the rule of ext/intl/msgformat/msgformat_helpers.cpp change the $(CC) to $(CXX) then run: sed -i '/EXTRA_LIBS = /s|$| -lstdc++|' Makefile [2013-03-08 16:27:05] 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. [2012-10-26 02:59:59] 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. [2012-09-11 16:27:47] re...@php.net Same for me, I can't compile either. hope there is a solution 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=48795 -- Edit this bug report at https://bugs.php.net/bug.php?id=48795edit=1
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795edit=1 ID: 48795 Comment by: cornelius dot howl at gmail dot com Reported by:gwy...@php.net 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: Quick fix for this 5.3.28 should work edit Makefile and found the rule of ext/intl/msgformat/msgformat_helpers.cpp change the $(CC) to $(CXX) then run: sed -i '/EXTRA_LIBS = /s|$| -lstdc++|' Makefile Previous Comments: [2013-03-08 16:27:05] 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. [2012-10-26 02:59:59] 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. [2012-09-11 16:27:47] re...@php.net Same for me, I can't compile either. hope there is a solution [2012-05-08 13:11:12] k...@php.net Also happens again with PHP 5.3.12 on Ubuntu 12.04 -- stas fix confirmed. A generic solution would be nice, indeed. [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. 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=48795 -- Edit this bug report at https://bugs.php.net/bug.php?id=48795edit=1
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795edit=1 ID: 48795 Comment by: cornelius dot howl at gmail dot com Reported by:gwy...@php.net 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: For this issue, here is the patch in phpbrew https://github.com/c9s/phpbrew/commit/18ef766d0e013ee87ac7d86e338ebec89fbeb445 Previous Comments: [2013-03-09 10:12:31] cornelius dot howl at gmail dot com Quick fix for this 5.3.28 should work edit Makefile and found the rule of ext/intl/msgformat/msgformat_helpers.cpp change the $(CC) to $(CXX) then run: sed -i '/EXTRA_LIBS = /s|$| -lstdc++|' Makefile [2013-03-08 16:27:05] 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. [2012-10-26 02:59:59] 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. [2012-09-11 16:27:47] re...@php.net Same for me, I can't compile either. hope there is a solution [2012-05-08 13:11:12] k...@php.net Also happens again with PHP 5.3.12 on Ubuntu 12.04 -- stas fix confirmed. A generic solution would be nice, indeed. 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=48795 -- Edit this bug report at https://bugs.php.net/bug.php?id=48795edit=1
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795edit=1 ID: 48795 Comment by: saltwaterc at gmail dot com Reported by:gwy...@php.net 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: 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. Previous Comments: [2012-10-26 02:59:59] 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. [2012-09-11 16:27:47] re...@php.net Same for me, I can't compile either. hope there is a solution [2012-05-08 13:11:12] k...@php.net Also happens again with PHP 5.3.12 on Ubuntu 12.04 -- stas fix confirmed. A generic solution would be nice, indeed. [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] weierophin...@php.net I can confirm Stas's suggestion (s/CC/CXX/ in BUILD_* vars) works with 5.4.0RC1 on linux 64-bit. 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=48795 -- Edit this bug report at https://bugs.php.net/bug.php?id=48795edit=1
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795edit=1
ID: 48795
Comment by: pgarvin76 at gmail dot com
Reported by:gwy...@php.net
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:
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.
Previous Comments:
[2012-09-11 16:27:47] re...@php.net
Same for me, I can't compile either. hope there is a solution
[2012-05-08 13:11:12] k...@php.net
Also happens again with PHP 5.3.12 on Ubuntu 12.04 -- stas fix confirmed. A
generic solution would be nice, indeed.
[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] weierophin...@php.net
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] ahar...@php.net
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
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795edit=1
ID: 48795
Comment by: re...@php.net
Reported by:gwy...@php.net
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:
Same for me, I can't compile either. hope there is a solution
Previous Comments:
[2012-05-08 13:11:12] k...@php.net
Also happens again with PHP 5.3.12 on Ubuntu 12.04 -- stas fix confirmed. A
generic solution would be nice, indeed.
[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] weierophin...@php.net
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] ahar...@php.net
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.
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795edit=1
ID: 48795
Comment by: k...@php.net
Reported by:gwy...@php.net
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] weierophin...@php.net
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] ahar...@php.net
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.
[2011-07-01 16:23:27] harald dot lapp at gmail dot com
just setting the EXTRA_LIBS did not work for me, but
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795edit=1
ID: 48795
Comment by: dan at cdchase dot com
Reported by:gwy...@php.net
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:
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.
Previous Comments:
[2011-11-14 16:54:00] weierophin...@php.net
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] ahar...@php.net
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.
[2011-07-01 16:23:27] 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!
[2010-06-17 19:43:39] henrik at bearwoods dot dk
I have tried the above quick-fixes and
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795edit=1
ID: 48795
Comment by: weierophin...@php.net
Reported by:gwy...@php.net
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:
I can confirm Stas's suggestion (s/CC/CXX/ in BUILD_* vars) works with 5.4.0RC1
on linux 64-bit.
Previous Comments:
[2011-11-11 11:30:21] ahar...@php.net
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.
[2011-07-01 16:23:27] 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!
[2010-06-17 19:43:39] 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)
[2010-05-24 21:19:51] s...@php.net
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
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795edit=1 ID: 48795 Comment by: luke at cywh dot com Reported by:gwy...@php.net Summary:Building intl 64-bit fails on OS X Status: Verified Type: Bug Package:Compile Failure Operating System: Mac OS X 10.5.8, 10.6.2 PHP Version:5.3SVN-2009-11-23 (SVN) Block user comment: N Private report: N New Comment: 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. Previous Comments: [2011-07-01 16:23:27] 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! [2010-06-17 19:43:39] 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) [2010-05-24 21:19:51] s...@php.net 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-04-20 19:31:52] 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-02-10 14:05:58] surfchen at gmail dot com It is a linking problem, here is the simple workaround: edit Makefile and add -lstdc++ into EXTRA_LIBS. 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=48795 -- Edit this bug report at https://bugs.php.net/bug.php?id=48795edit=1
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795edit=1 ID: 48795 Comment by: harald dot lapp at gmail dot com Reported by:gwy...@php.net Summary:Building intl 64-bit fails on OS X Status: Verified Type: Bug Package:Compile Failure Operating System: Mac OS X 10.5.8, 10.6.2 PHP Version:5.3SVN-2009-11-23 (SVN) Block user comment: N Private report: N New Comment: 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! Previous Comments: [2010-06-17 19:43:39] 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) [2010-05-24 21:19:51] s...@php.net 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-04-20 19:31:52] 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-02-10 14:05:58] surfchen at gmail dot com It is a linking problem, here is the simple workaround: edit Makefile and add -lstdc++ into EXTRA_LIBS. [2010-01-10 11:54:55] harald dot lapp at gmail dot com same problem here: osx 10.5.8, php5.3-latest any ideas how to fix this issue? 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=48795 -- Edit this bug report at https://bugs.php.net/bug.php?id=48795edit=1
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at http://bugs.php.net/bug.php?id=48795edit=1 ID: 48795 Comment by: henrik at bearwoods dot dk Reported by: gwy...@php.net Summary: Building intl 64-bit fails on OS X Status: Verified Type: Bug Package: Compile Failure Operating System: Mac OS X 10.5.8, 10.6.2 PHP Version: 5.3SVN-2009-11-23 (SVN) New Comment: 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) Previous Comments: [2010-05-24 21:19:51] s...@php.net 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-04-20 19:31:52] 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-02-10 14:05:58] surfchen at gmail dot com It is a linking problem, here is the simple workaround: edit Makefile and add -lstdc++ into EXTRA_LIBS. [2010-01-10 11:54:55] harald dot lapp at gmail dot com same problem here: osx 10.5.8, php5.3-latest any ideas how to fix this issue? [2009-11-24 11:46:48] j...@php.net well, build system does handle C++ quite fine for me. OSX is special.. 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 http://bugs.php.net/bug.php?id=48795 -- Edit this bug report at http://bugs.php.net/bug.php?id=48795edit=1
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at http://bugs.php.net/bug.php?id=48795edit=1 ID: 48795 Comment by: fsb at thefeb dot org Reported by: gwy...@php.net Summary: Building intl 64-bit fails on OS X Status: Verified Type: Bug Package: Compile Failure Operating System: Mac OS X 10.5.8, 10.6.2 PHP Version: 5.3SVN-2009-11-23 (SVN) New Comment: 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. Previous Comments: [2010-02-10 14:05:58] surfchen at gmail dot com It is a linking problem, here is the simple workaround: edit Makefile and add -lstdc++ into EXTRA_LIBS. [2010-01-10 11:54:55] harald dot lapp at gmail dot com same problem here: osx 10.5.8, php5.3-latest any ideas how to fix this issue? [2009-11-24 11:46:48] j...@php.net well, build system does handle C++ quite fine for me. OSX is special.. [2009-11-24 01:23:26] gwy...@php.net No, upgrading the bundled libtool didn't fix it. The buildsystem isn't set up to deal with C++ files automatically. [2009-11-23 21:58:18] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ 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 http://bugs.php.net/bug.php?id=48795 -- Edit this bug report at http://bugs.php.net/bug.php?id=48795edit=1
