Hi, Ian Lance Taylor <i...@google.com> skribis:
> ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> Ian Lance Taylor <i...@google.com> skribis: >> >>> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >>> >>>> Ian Lance Taylor <i...@google.com> skribis: >>>> >>>>> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >>>>> >>>>>> However, this means that plug-ins must now be built with g++, except >>>>>> when GCC was configured with --disable-build-poststage1-with-cxx. This >>>>>> seems difficult to deal with, for plug-in writers. >>>>> >>>>> This is an unfortunate truth during our transition to building gcc with >>>>> 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 <plugin-api.h> is for linker plug-ins; <gcc-plugin.h> provides nothing more than the event mechanism. Symbols declared in <tree.h> are mangled, for instance. I’m not sure whether <tree.h> 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–i.e., either mangled 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’.
