* status of GCC & C++ @ 2012-03-25 17:19 Basile Starynkevitch 2012-03-25 17:25 ` Diego Novillo 2012-03-27 10:23 ` status of GCC & C++ Ludovic Courtès 0 siblings, 2 replies; 19+ messages in thread From: Basile Starynkevitch @ 2012-03-25 17:19 UTC (permalink / raw) To: gcc Hello All, It seems that several Linux distributions are shipping a GCC 4.7 compiled by a C++ compiler (probably GCC). This affects plugins makers, as has been already discussed. Do we have (e.g. for plugin makers) a nice way to know if a given GCC distribution was compiled in C or in C++ mode? For instance, compiling a helloworld.c with gcc -v don't tell anything about the way that GCC compiler has been built. (ie if it has C++ symbols or C ones in the executable, and knowing that is mandatory for plugins). Did we cross the C++ rubicon, in other words is GCC 4.8 scheduled to be compilable with a C compiler (not C++) for the C front-end and the middle-end and the x86_64/GNU/Linux back-end? [my imperfect understanding was that GCC 4.7 should have been compilable by either a standard C89 or a standard C++03 compiler, if not needing a Go or Ada front-end] When GCC won't be compilable any more by a C (not C++) compiler, should we make that a prominent & documented change? I believe it should also be reflected in our configure machinery (by rejecting the build of GCC when a C++ compiler is not available). Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: status of GCC & C++ 2012-03-25 17:19 status of GCC & C++ Basile Starynkevitch @ 2012-03-25 17:25 ` Diego Novillo 2012-03-25 17:33 ` Eric Botcazou [not found] ` <20120325192843.05bf843acfb715c4bc9cd4aa@starynkevitch.net> 2012-03-27 10:23 ` status of GCC & C++ Ludovic Courtès 1 sibling, 2 replies; 19+ messages in thread From: Diego Novillo @ 2012-03-25 17:25 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: gcc On 3/25/12 1:19 PM, Basile Starynkevitch wrote: > When GCC won't be compilable any more by a C (not C++) compiler, should we make that a > prominent& documented change? I believe it should also be reflected in our configure > machinery (by rejecting the build of GCC when a C++ compiler is not available). Yes. For GCC 4.8, we should move to: - Build all stages with C++ - Remove the option to go back to C. Diego. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: status of GCC & C++ 2012-03-25 17:25 ` Diego Novillo @ 2012-03-25 17:33 ` Eric Botcazou 2012-03-25 17:44 ` Diego Novillo [not found] ` <20120325192843.05bf843acfb715c4bc9cd4aa@starynkevitch.net> 1 sibling, 1 reply; 19+ messages in thread From: Eric Botcazou @ 2012-03-25 17:33 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc, Basile Starynkevitch > Yes. For GCC 4.8, we should move to: > > - Build all stages with C++ > - Remove the option to go back to C. That would mean you can start to use C++ in the compiler code although, AFAIK, we are still waiting for the long-promised C++ Coding Standard. That seems like putting the car before the horses to me. -- Eric Botcazou ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: status of GCC & C++ 2012-03-25 17:33 ` Eric Botcazou @ 2012-03-25 17:44 ` Diego Novillo 2012-03-25 21:37 ` Eric Botcazou 0 siblings, 1 reply; 19+ messages in thread From: Diego Novillo @ 2012-03-25 17:44 UTC (permalink / raw) To: Eric Botcazou; +Cc: gcc, Basile Starynkevitch On 3/25/12 1:32 PM, Eric Botcazou wrote: >> Yes. For GCC 4.8, we should move to: >> >> - Build all stages with C++ >> - Remove the option to go back to C. > > That would mean you can start to use C++ in the compiler code although, AFAIK, > we are still waiting for the long-promised C++ Coding Standard. That seems > like putting the car before the horses to me. I don't think so. By simply causing stage 1 to be compilable with a C++ compiler, we are making the transition easier. This is orthogonal to the porting effort. The proposed coding guidelines have been published and will evolve (http://gcc.gnu.org/wiki/CppConventions). No point waiting to settle a set of rules that will naturally change over time, as we start using it. Diego. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: status of GCC & C++ 2012-03-25 17:44 ` Diego Novillo @ 2012-03-25 21:37 ` Eric Botcazou 2012-03-25 21:46 ` Diego Novillo 0 siblings, 1 reply; 19+ messages in thread From: Eric Botcazou @ 2012-03-25 21:37 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc, Basile Starynkevitch > The proposed coding guidelines have been published and will evolve > (http://gcc.gnu.org/wiki/CppConventions). No point waiting to settle a > set of rules that will naturally change over time, as we start using it. That isn't what was decided when the transition to C++ was proposed though. It was agreed that a set of Coding Conventions would be published before the switch to C++. If you think that the above conventions are in good enough a shape to be proposed, then propose them for inclusion in http://gcc.gnu.org/codingconventions.html -- Eric Botcazou ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: status of GCC & C++ 2012-03-25 21:37 ` Eric Botcazou @ 2012-03-25 21:46 ` Diego Novillo 2012-03-25 22:01 ` Gabriel Dos Reis 2012-03-28 19:50 ` Eric Botcazou 0 siblings, 2 replies; 19+ messages in thread From: Diego Novillo @ 2012-03-25 21:46 UTC (permalink / raw) To: Eric Botcazou; +Cc: gcc, Basile Starynkevitch On Sun, Mar 25, 2012 at 17:36, Eric Botcazou <ebotcazou@adacore.com> wrote: >> The proposed coding guidelines have been published and will evolve >> (http://gcc.gnu.org/wiki/CppConventions). No point waiting to settle a >> set of rules that will naturally change over time, as we start using it. > > That isn't what was decided when the transition to C++ was proposed though. Really? To start *writing* in C++, sure we want at least an initial version of the coding guidelines. I pointed to those, because they look like a reasonable start. To start *building* in C++, I do not think we need to agree on the coding guidelines. We are already doing stages 2 and 3, doing stage 1 is a straightforward next step. > It was agreed that a set of Coding Conventions would be published before the > switch to C++. If you think that the above conventions are in good enough a > shape to be proposed, then propose them for inclusion in > http://gcc.gnu.org/codingconventions.html This needs to be done, yes. But not for simply building with C++. Diego. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: status of GCC & C++ 2012-03-25 21:46 ` Diego Novillo @ 2012-03-25 22:01 ` Gabriel Dos Reis 2012-03-28 19:50 ` Eric Botcazou 1 sibling, 0 replies; 19+ messages in thread From: Gabriel Dos Reis @ 2012-03-25 22:01 UTC (permalink / raw) To: Diego Novillo; +Cc: Eric Botcazou, gcc, Basile Starynkevitch On Sun, Mar 25, 2012 at 4:45 PM, Diego Novillo <dnovillo@google.com> wrote: > To start *building* in C++, I do not think we need to agree on the > coding guidelines. We are already doing stages 2 and 3, doing stage 1 > is a straightforward next step. I agree with Diego that to start building only with a C++ compiler, we do not need to have approved a C++ coding convention. I also think that the current wiki page is still at brainstorming phase than a sufficiently complete and coherent set. It needs further flushing. For example, I do not believe it makes sense to ban both simple templates (for writing containers) and virtual functions (or to that matter multiple inheritance). There are forms of those features that need to be properly restricted (e.g. it would a real mistake to go banana with the "advanced" template (meta)programming stuff.) Similarly, some of the control/flow and path can be significantly reduced (and bugs fixed!) if simple exception handling is allowed -- think of all those bugs caused by failure to exit early on error_mark_node. -- Gaby ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: status of GCC & C++ 2012-03-25 21:46 ` Diego Novillo 2012-03-25 22:01 ` Gabriel Dos Reis @ 2012-03-28 19:50 ` Eric Botcazou 1 sibling, 0 replies; 19+ messages in thread From: Eric Botcazou @ 2012-03-28 19:50 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc, Basile Starynkevitch > Really? To start *writing* in C++, sure we want at least an initial > version of the coding guidelines. I pointed to those, because they > look like a reasonable start. > > To start *building* in C++, I do not think we need to agree on the > coding guidelines. We are already doing stages 2 and 3, doing stage 1 > is a straightforward next step. If we start building in C++, then this would mean that you can start to use C++ in the code. And we agreed to settle on a set of coding guidelines before starting to use C++ in the code. Building stage 1 with a C++ compiler has zero value if you don't use C++ in the code. It probably even has a negative value, since it gratuitously makes it harder to build the compiler on exotic platforms. -- Eric Botcazou ^ permalink raw reply [flat|nested] 19+ messages in thread
[parent not found: <20120325192843.05bf843acfb715c4bc9cd4aa@starynkevitch.net>]
[parent not found: <4F6F5E48.90404@google.com>]
* Re: status of GCC & C++ [not found] ` <4F6F5E48.90404@google.com> @ 2012-03-25 18:31 ` Basile Starynkevitch 2012-03-25 20:11 ` Basile Starynkevitch 0 siblings, 1 reply; 19+ messages in thread From: Basile Starynkevitch @ 2012-03-25 18:31 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc On Sun, 25 Mar 2012 14:04:56 -0400 Diego Novillo <dnovillo@google.com> wrote: > On 3/25/12 1:28 PM, Basile Starynkevitch wrote: > > On Sun, 25 Mar 2012 13:25:34 -0400 [...] > > I would suggest then to put in a core header file (even used by plugins) something like > > #ifndef __cpluscplus > > #error GCC and its plugins need to be compiled by a C++ compiler > > #endif > > > > What do you think? And where should we put that? > > First things first. Stage 1 should be compiled with C++. We still need > someone to volunteer to do that. Ok. I thought that step was a trivial one. Now a related question. How can a plugin know that cc1 was compiled with C++ or just with plain C? I don't really know (we do have GCCPLUGIN_VERSION, but should a plugin use ENABLE_BUILD_WITH_CXX)? And I don't understand why the GCC 4.7 changes don't advertise loudly on http://gcc.gnu.org/gcc-4.7/changes.html that the C language is obsolete as the language in which GCC is coded, and that next release will *need* to be compiled with C++? Or is something that tells it somewhere, in strong enough words or typography that nobody could skip it? (I am not sure that a casual user, brave enough to compile GCC 4.7 from source, did notice that C++ would be soon mandatory to compile GCC). Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: status of GCC & C++ 2012-03-25 18:31 ` Basile Starynkevitch @ 2012-03-25 20:11 ` Basile Starynkevitch 2012-03-25 20:21 ` Gabriel Dos Reis ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Basile Starynkevitch @ 2012-03-25 20:11 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: Diego Novillo, gcc On Sun, 25 Mar 2012 20:30:31 +0200 Basile Starynkevitch <basile@starynkevitch.net> wrote: > > How can a plugin know that cc1 was compiled with C++ or just with > plain C? I don't really know (we do have GCCPLUGIN_VERSION, but should a plugin use > ENABLE_BUILD_WITH_CXX)? Actually, I tend to believe that this is really a bug in GCC 4.7 (specifically). I think that A) gcc-4.7 -v should obviously tell if it was compiled in C++ mode or in C mode, since this information is crucial to plugins. On Debian/Sid I don't have a simple way to get that information. % /usr/bin/gcc-4.7 -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc-4.7 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.0-1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c+ +,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c+ +/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.0 (Debian 4.7.0-1) Nothing above tell me about GCC being compiled in C++ flavor B) the $(gcc-4.7 -print-file-name=plugin)/ directory should have a header file with something telling if it was compiled in C++ or C mode. (Perhaps ENABLE_BUILD_WITH_GCC might have that role in auto-host.h, but then I think it is grossly misnamed). Since 4.7 is probably the only release of GCC which can be compiled by C and by C++ I believe it is a bug specific to that release. I'm sure this bug affect several GCC plugins. It does affect GCC MELT for instance. https://groups.google.com/forum/?fromgroups#!topic/gcc-melt/PRWr28sQExk My feeling is that it is not only the plugins' fault (so it is not only a MELT plugin bug, but a GCC one) What do you think? Should 4.7.1 provide a fix to correct that? How? Testing simply ENABLE_BUILD_WITH_GCC makes me feel unhappy; that name is really confusing, if we understand and use it as GCC_IS_BUILT_WITH_CXX My wish would be to add, perhaps in gcc/configure.ac of GCC 4.7.1, something which defines GCCPLUGIN_IN_CXX in e.g. $(gcc-4.7 -print-file-name=plugin)/plugin-version.h when gcc-4.7 have been built with a C++ compiler so its plugins need to be compiled with a C++ compiler. That information should also be accessible (e.g. for plugin makers) thru some invocation of GCC (perhaps gcc -v). Cheers PS. Compatibility with C++ plugins was already discussed, but I forgot when... Here I focus on a possible bug of GCC 4.7. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: status of GCC & C++ 2012-03-25 20:11 ` Basile Starynkevitch @ 2012-03-25 20:21 ` Gabriel Dos Reis 2012-03-25 20:29 ` Marc Glisse 2012-03-26 15:59 ` Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++) David Malcolm 2 siblings, 0 replies; 19+ messages in thread From: Gabriel Dos Reis @ 2012-03-25 20:21 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: Diego Novillo, gcc On Sun, Mar 25, 2012 at 3:10 PM, Basile Starynkevitch <basile@starynkevitch.net> wrote: > Nothing above tell me about GCC being compiled in C++ flavor I believe the ones that are not compiled with a C++ compiler have a --disable-xxx-something in the output of gcc -v -- Gaby ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: status of GCC & C++ 2012-03-25 20:11 ` Basile Starynkevitch 2012-03-25 20:21 ` Gabriel Dos Reis @ 2012-03-25 20:29 ` Marc Glisse 2012-03-26 15:59 ` Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++) David Malcolm 2 siblings, 0 replies; 19+ messages in thread From: Marc Glisse @ 2012-03-25 20:29 UTC (permalink / raw) To: gcc On Sun, 25 Mar 2012, Basile Starynkevitch wrote: > On Sun, 25 Mar 2012 20:30:31 +0200 > Basile Starynkevitch <basile@starynkevitch.net> wrote: >> >> How can a plugin know that cc1 was compiled with C++ or just with >> plain C? nm thefile | grep _Z (possibly nm -D) You can also look for --disable-bootstrap or --disable-build-with-cxx in the configure options. Or you can just assume that it is built as C++, which is the default after all. People who have anything different should have asked for it and thus know what to expect. -- Marc Glisse ^ permalink raw reply [flat|nested] 19+ messages in thread
* Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++) 2012-03-25 20:11 ` Basile Starynkevitch 2012-03-25 20:21 ` Gabriel Dos Reis 2012-03-25 20:29 ` Marc Glisse @ 2012-03-26 15:59 ` David Malcolm 2012-03-26 17:07 ` Joseph S. Myers 2 siblings, 1 reply; 19+ messages in thread From: David Malcolm @ 2012-03-26 15:59 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: Diego Novillo, gcc On Sun, 2012-03-25 at 22:10 +0200, Basile Starynkevitch wrote: > On Sun, 25 Mar 2012 20:30:31 +0200 > Basile Starynkevitch <basile@starynkevitch.net> wrote: > > > > How can a plugin know that cc1 was compiled with C++ or just with > > plain C? I don't really know (we do have GCCPLUGIN_VERSION, but should a plugin use > > ENABLE_BUILD_WITH_CXX)? > [...snip discussion of various ways to try to "ask" GCC whether it was built with a C or a C++ compiler...] > Since 4.7 is probably the only release of GCC which can be compiled by C and by C++ I > believe it is a bug specific to that release. > > I'm sure this bug affect several GCC plugins. It does affect GCC MELT for instance. > https://groups.google.com/forum/?fromgroups#!topic/gcc-melt/PRWr28sQExk As noted in another thread, it also affects the Python plugin: https://fedorahosted.org/pipermail/gcc-python-plugin/2012-March/000202.html https://fedorahosted.org/pipermail/gcc-python-plugin/2012-March/000204.html > My feeling is that it is not only the plugins' fault (so it is not only a MELT plugin > bug, but a GCC one) > > > What do you think? Should 4.7.1 provide a fix to correct that? How? Testing simply > ENABLE_BUILD_WITH_GCC makes me feel unhappy; that name is really confusing, if we > understand and use it as GCC_IS_BUILT_WITH_CXX Presumably a fix would be for the plugin's configuration phase to have a test that tries to build a test plugin and run it, first building with a C compiler, then a C++ compiler, and decides what compiler the real plugin should be built with accordingly. Presumably the only APIs that are guaranteed for use by plugins so far are the ones directly relating to plugins themselves: * plugin_default_version_check * register_callback I'd hoped that a suitable feature test might be a minimal test plugin that simply tries to call plugin_default_version_check() in its init function: that way the plugin_init can only run if the dynamic link succeeds, and you've got the correct compiler. However, annoyingly, in gcc-plugin.h http://gcc.gnu.org/viewcvs/trunk/gcc/gcc-plugin.h?revision=184997&view=markup 'extern "C"' guards are present around the relevant declarations, making these symbols unsuitable for use in a configure-time test. So are there any plugin-visible symbols that aren't yet wrapped in an extern "C"? (FWIW I've been working on a possible plugin API for GCC, similar to the one I posted in my earlier mail, trying to get my python plugin to compile against it, but I don't have anything working yet) > My wish would be to add, perhaps in gcc/configure.ac of GCC 4.7.1, something which > defines GCCPLUGIN_IN_CXX in e.g. $(gcc-4.7 -print-file-name=plugin)/plugin-version.h > when gcc-4.7 have been built with a C++ compiler so its plugins need to be compiled with > a C++ compiler. That information should also be accessible (e.g. for plugin makers) thru > some invocation of GCC (perhaps gcc -v). ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++) 2012-03-26 15:59 ` Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++) David Malcolm @ 2012-03-26 17:07 ` Joseph S. Myers 2012-03-26 18:18 ` David Malcolm 0 siblings, 1 reply; 19+ messages in thread From: Joseph S. Myers @ 2012-03-26 17:07 UTC (permalink / raw) To: David Malcolm; +Cc: Basile Starynkevitch, Diego Novillo, gcc On Mon, 26 Mar 2012, David Malcolm wrote: > Presumably a fix would be for the plugin's configuration phase to have a > test that tries to build a test plugin and run it, first building with a > C compiler, then a C++ compiler, and decides what compiler the real > plugin should be built with accordingly. We've previously discussed providing some generic configure / build support for plugins (standard autoconf macros intended for use in a plugin's build system, for example). If in future plugins are supported on Windows hosts (or any other hosts that lack a -rdynamic equivalent) then such generic support will be increasingly useful because of the need to link plugins on such hosts against a shared library or libraries that contain most of GCC. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++) 2012-03-26 17:07 ` Joseph S. Myers @ 2012-03-26 18:18 ` David Malcolm 2012-03-26 18:33 ` Basile Starynkevitch 0 siblings, 1 reply; 19+ messages in thread From: David Malcolm @ 2012-03-26 18:18 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Basile Starynkevitch, Diego Novillo, gcc On Mon, 2012-03-26 at 17:07 +0000, Joseph S. Myers wrote: > On Mon, 26 Mar 2012, David Malcolm wrote: > > > Presumably a fix would be for the plugin's configuration phase to have a > > test that tries to build a test plugin and run it, first building with a > > C compiler, then a C++ compiler, and decides what compiler the real > > plugin should be built with accordingly. > > We've previously discussed providing some generic configure / build > support for plugins (standard autoconf macros intended for use in a > plugin's build system, for example). If in future plugins are supported > on Windows hosts (or any other hosts that lack a -rdynamic equivalent) > then such generic support will be increasingly useful because of the need > to link plugins on such hosts against a shared library or libraries that > contain most of GCC. I suppose now is a bad time to mention that my python plugin *doesn't* use autoconf for its configure script - I didn't want to use m4 given that python is available. I'm sure I'll figure something out though. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++) 2012-03-26 18:18 ` David Malcolm @ 2012-03-26 18:33 ` Basile Starynkevitch 2012-03-26 20:34 ` Romain Geissler 0 siblings, 1 reply; 19+ messages in thread From: Basile Starynkevitch @ 2012-03-26 18:33 UTC (permalink / raw) To: David Malcolm; +Cc: Joseph S. Myers, Diego Novillo, gcc On Mon, 26 Mar 2012 13:13:22 -0400 David Malcolm <dmalcolm@redhat.com> wrote: > On Mon, 2012-03-26 at 17:07 +0000, Joseph S. Myers wrote: > > On Mon, 26 Mar 2012, David Malcolm wrote: > > > > I suppose now is a bad time to mention that my python plugin *doesn't* > use autoconf for its configure script - I didn't want to use m4 given > that python is available. I'm sure I'll figure something out though. For what it is worth, the MELT plugin don't use autoconf. And I still think that GCC 4.7.1 should be able to tell by itself if it was compiled by C or by C++. Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++) 2012-03-26 18:33 ` Basile Starynkevitch @ 2012-03-26 20:34 ` Romain Geissler 2012-03-27 5:53 ` Basile Starynkevitch 0 siblings, 1 reply; 19+ messages in thread From: Romain Geissler @ 2012-03-26 20:34 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: David Malcolm, Joseph S. Myers, Diego Novillo, gcc Hi, Le 26 mars 2012 à 20:33, Basile Starynkevitch a écrit : > > And I still think that GCC 4.7.1 should be able to tell by itself if it was compiled by C > or by C++. > Actually you can already find it for every GCC version you are interested in (4.6.x and 4.7.x), with very little logic, as it was pointed out to you yesterday here http://gcc.gnu.org/ml/gcc/2012-03/msg00381.html and here http://gcc.gnu.org/ml/gcc/2012-03/msg00382.html (the solution with gcc -v as using nm is not a portable solution). This will work in most case : the targeted GCC you want to build a plugin for can be run on the build machine. If you need to be able to cross-build a plugin on arch A for a targeted GCC running on host arch B, then you won't be able to invoke gcc -v. Anyway there is a a solution that works all the time, all you need is being able to grep in a file for a given pattern. Just take a look at the following file : $(gcc -print-file-name=plugin)/include/auto-host.h You'll find something like this : /* Define if building with C++. */ #ifndef USED_FOR_TARGET #define ENABLE_BUILD_WITH_CXX 1 #endif So that's it, you already got all you need for all version. Cheers Romain Geissler ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++) 2012-03-26 20:34 ` Romain Geissler @ 2012-03-27 5:53 ` Basile Starynkevitch 0 siblings, 0 replies; 19+ messages in thread From: Basile Starynkevitch @ 2012-03-27 5:53 UTC (permalink / raw) To: Romain Geissler; +Cc: David Malcolm, Joseph S. Myers, Diego Novillo, gcc On Mon, 26 Mar 2012 22:34:22 +0200 Romain Geissler <romain.geissler@gmail.com> wrote: > Hi, > You'll find something like this : > > /* Define if building with C++. */ > #ifndef USED_FOR_TARGET > #define ENABLE_BUILD_WITH_CXX 1 > #endif > > So that's it, you already got all you need for all version. > I did mention ENABLE_BUILD_WITH_CXX in previous email, but I am not very satisfied by this solution. I really think that GCC 4.7 should explicitly tell, e.g. thru gcc -v, how it was compiled (ie in C or in C++ mode). This would help a lot plugin package makers (not the same as plugin developers). Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: status of GCC & C++ 2012-03-25 17:19 status of GCC & C++ Basile Starynkevitch 2012-03-25 17:25 ` Diego Novillo @ 2012-03-27 10:23 ` Ludovic Courtès 1 sibling, 0 replies; 19+ messages in thread From: Ludovic Courtès @ 2012-03-27 10:23 UTC (permalink / raw) To: gcc Hi Basile, Basile Starynkevitch <basile@starynkevitch.net> skribis: > Do we have (e.g. for plugin makers) a nice way to know if a given GCC distribution was > compiled in C or in C++ mode? Iâve written an Autoconf macro that does that: http://gcc.gnu.org/ml/gcc/2012-03/msg00240.html Thanks, Ludoâ. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2012-03-28 19:50 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-25 17:19 status of GCC & C++ Basile Starynkevitch 2012-03-25 17:25 ` Diego Novillo 2012-03-25 17:33 ` Eric Botcazou 2012-03-25 17:44 ` Diego Novillo 2012-03-25 21:37 ` Eric Botcazou 2012-03-25 21:46 ` Diego Novillo 2012-03-25 22:01 ` Gabriel Dos Reis 2012-03-28 19:50 ` Eric Botcazou [not found] ` <20120325192843.05bf843acfb715c4bc9cd4aa@starynkevitch.net> [not found] ` <4F6F5E48.90404@google.com> 2012-03-25 18:31 ` Basile Starynkevitch 2012-03-25 20:11 ` Basile Starynkevitch 2012-03-25 20:21 ` Gabriel Dos Reis 2012-03-25 20:29 ` Marc Glisse 2012-03-26 15:59 ` Configure-time testing for GCC plugins to determine C vs C++? (Was Re: status of GCC & C++) David Malcolm 2012-03-26 17:07 ` Joseph S. Myers 2012-03-26 18:18 ` David Malcolm 2012-03-26 18:33 ` Basile Starynkevitch 2012-03-26 20:34 ` Romain Geissler 2012-03-27 5:53 ` Basile Starynkevitch 2012-03-27 10:23 ` status of GCC & C++ Ludovic Courtès
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).