On Mon, 2012-02-27 at 10:43 -0600, Richard Lynch wrote:
> 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



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to