Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58166 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16980 invoked from network); 27 Feb 2012 18:19:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Feb 2012 18:19:21 -0000 Authentication-Results: pb1.pair.com smtp.mail=johannes@schlueters.de; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=johannes@schlueters.de; sender-id=unknown Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error) X-PHP-List-Original-Sender: johannes@schlueters.de X-Host-Fingerprint: 217.114.211.66 config.schlueters.de Received: from [217.114.211.66] ([217.114.211.66:54855] helo=config.schlueters.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 00/02-40985-829CB4F4 for ; Mon, 27 Feb 2012 13:19:21 -0500 Received: from [192.168.2.230] (ppp-93-104-28-210.dynamic.mnet-online.de [93.104.28.210]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by config.schlueters.de (Postfix) with ESMTPSA id 8D2F4601B4; Mon, 27 Feb 2012 19:19:17 +0100 (CET) To: Richard Lynch Cc: PHP Internals In-Reply-To: <947424542e69779fff453a9c4748f58a.squirrel@www.l-i-e.com> References: <947424542e69779fff453a9c4748f58a.squirrel@www.l-i-e.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 27 Feb 2012 19:19:16 +0100 Message-ID: <1330366756.2159.47.camel@guybrush> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Cannot build ext/intl on Fedora 15 From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=) 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