Cannot build ext/intl on Fedora 15 View as Markdown

Hmm.

Here is my apt-get install line, starting from a stock install of
11.10 in virtualbox:

apt-get -y install build-essential apache2 libxml2-dev libcurl4-openssl-dev
libcurl4-openssl-dev libjpeg-dev libpng-dev libfreetype6-dev libicu-dev
libmcrypt-dev mysql-server mysql-client libmysqlclient-dev libxslt-dev
autoconf libltdl-dev

Then I pull down 5.3.10, cd to it and run this configure line:

'./configure' '--enable-fastcgi' '--with-gd' '--with-pdo-mysql'
'--with-curl' '--with-mysql' '--with-freetype-dir=/usr'
'--with-jpeg-dir=/usr' '--with-mcrypt' '--with-zlib'
'--enable-mbstring' '--enable-ftp' '--with-xsl' '--with-openssl'
'--with-kerberos' '--enable-exif' '--enable-intl'

I then run 'make', which bombs with the error mentioned at link time
unless I add -lstdc++ manually.

Anyone see a missing package that makes build-essential a little more
essential? (:

I'll try this again in a fresh install of ubuntu 11.x (shoot, forgot
to take a virtualbox snapshot last time).

Bump - this is still a live issue on Ubuntu 11.10, for instance.

I just hacked my Ubuntu PHP-from-source installer to touch up the
Makefile by prepending -lstdc++ to EXTRA_LIBS. That does the job.

Which I knew more about autoconf, I'd like to help figure this out
properly so everyone doesn't wind up maintaining hacks to compile PHP
from source. It discourages a very large community from trying new
releases.

Is this perhaps because some of the code being included in the PHP
build happens to be C++ code? (Not readily apparent from the outside
of course.)

My dev box is Ubuntu 11.10 and I have no issues building ext/intl.

-Rasmus

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

Bump - this is still a live issue on Ubuntu 11.10, for instance.

I just hacked my Ubuntu PHP-from-source installer to touch up the
Makefile by prepending -lstdc++ to EXTRA_LIBS. That does the job.

Which I knew more about autoconf, I'd like to help figure this out
properly so everyone doesn't wind up maintaining hacks to compile PHP
from source. It discourages a very large community from trying new
releases.

Is this perhaps because some of the code being included in the PHP
build happens to be C++ code? (Not readily apparent from the outside
of course.)

I believe core PHP is all in C.

Extensions, however, could be in C++

ext/intl contains one or two c++ files.

-Hannes

I believe core PHP is all in C.

Correct.

Extensions, however, could be in C++

Correct.

And if one extension has forgotten to edit the Makefiles to do
-lstdc++ I presume that it could be the cause.

Nobody should directly link -lstdc++, that name is compiler-specific.
Instead a C++ compiler has to be used in this case for the final
linkage, so instead of linking using gcc one has to use g++ when using a
gcc chain.

For shared builds the build system has a flag to switch this. When
building PHP itself the build system ignores that flag. (that's where
the tip to build it shared came from)

I'd even hazard a guess that it would only surface if one disabled
other extensions that generally PRECEDE it in the configure / make
process, as once the -lstdc++ is in there, it remains for the rest of
the build process. This is just a guess, however...

No, as no extension should refer to libstdc++ (see above) this is not
the case.
A reason one one might not see it is that PHP is linked against a
library which was linked using libstdc++ and therefore pulls it in.
(So if ext/foo was a wrapper around libfoo.so and libfoo.so would be
linked using a C++ compiler this would work)

At any rate, if you could eliminate each extension, one by one, you
might find the culprit, assuming my guesses are valid.

There are two possible solutions:

  * change the build system to link php using the C++ compiler to
    pull in the C++ standard lib. This might have some issues on
    portability of the binary, make the process larger, etc.
  * figure out which C++ things are being used that require the C++
    standard library and get rid of them. I didn't look into this
    but it seems libintl doesn't need the C++ standard lib (else it
    should pull it in) and the error message refering to
    __gxx_personality_v0 sounds like a compiler feature which might
    be controlled by using some compiler flags. My guess is that
    this is part of gcc's exception or RTTI implementation which can
    be disabled (try -fno-rtti or -fno-exception in CXXFLAGS) ... if
    this is the case disabling these features for these files would
    be the fest thing to do. (while it causes trouble if it is done
    for other [future or pecl?]) files which might need these
    features

johannes