From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10598 invoked by alias); 12 Mar 2012 08:56:56 -0000 Received: (qmail 10590 invoked by uid 22791); 12 Mar 2012 08:56:55 -0000 X-SWARE-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail4-relais-sop.national.inria.fr (HELO mail4-relais-sop.national.inria.fr) (192.134.164.105) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 12 Mar 2012 08:56:41 +0000 Received: from unknown (HELO pluto) ([193.50.110.167]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 12 Mar 2012 09:56:22 +0100 From: ludovic.courtes@inria.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) To: Ian Lance Taylor Cc: Andrew Pinski , gcc@gcc.gnu.org Subject: Re: GCC 4.7.0RC: Mangled names in cc1 References: <877gyu85mc.fsf@inria.fr> <87ty1y6oq2.fsf@inria.fr> <877gytvl0o.fsf@inria.fr> <87r4x1r9re.fsf@inria.fr> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 23 =?iso-8859-1?Q?Vent=F4se?= an 220 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Date: Mon, 12 Mar 2012 08:56:00 -0000 In-Reply-To: (Ian Lance Taylor's message of "Fri, 09 Mar 2012 10:08:05 -0800") Message-ID: <87pqciurih.fsf@inria.fr> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-03/txt/msg00151.txt.bz2 Hi, Ian Lance Taylor skribis: > ludovic.courtes@inria.fr (Ludovic Court=C3=A8s) writes: > >> Ian Lance Taylor skribis: >> >>> ludovic.courtes@inria.fr (Ludovic Court=C3=A8s) writes: >>> >>>> Ian Lance Taylor skribis: >>>> >>>>> ludovic.courtes@inria.fr (Ludovic Court=C3=A8s) writes: >>>>> >>>>>> However, this means that plug-ins must now be built with g++, except >>>>>> when GCC was configured with --disable-build-poststage1-with-cxx. T= his >>>>>> seems difficult to deal with, for plug-in writers. >>>>> >>>>> This is an unfortunate truth during our transition to building gcc wi= th >>>>> C++. There is going to be a period of time when the compiler may be >>>>> built as either C or C++. The end goal is for the compiler to always= be >>>>> built with C++, but until we reach that state I think plugin writers >>>>> will have to test. >>>> >>>> What about wrapping the C API in extern "C"? >>> >>> We eventually will want the internal APIs to be C++, so this transition >>> will inevitably happen at some point. >> >> I understand the goal. However, should a C++ API be added, the C-only >> part could still be kept extern "C". > > We are talking here about internal GCC functions. We are not talking > about an actual defined API. The defined API is in plugin-api.h, and > that remains extern "C". There is no "C-only part" of the internal API. Hmm is for linker plug-ins; provides nothing more than the event mechanism. Symbols declared in are mangled, for instance. I=E2=80=99m not su= re whether is considered internal or not, but I can hardly see what kind of plug-in could be written without using it. >> For 4.7.0, as Duncan Sands writes, it would be a very helpful for the >> ABI to be independent of configuration options=E2=80=93i.e., either mang= led or >> unmangled symbols. > > That just postpones the pain to gcc 4.8.0. In 4.8 things will be easier: plug-ins will have to be compiled with g++. In 4.7, finding out whether gcc or g++ should be used is left as an exercise to the plug-in writer, which is inconvenient at best. Thanks, Ludo=E2=80=99.