GCC compatibility layer going too far?

Hi,

A project I work on produces a GCC plug-in. A ‘configure’ macro aims to
check whether GCC is being used, and whether it supports plug-ins:

  https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?view=markup&revision=5169&root=starpu&pathrev=5202

Despite being fairly elaborate, the macro returns “yes” for Clang 3.1.
However, Clang isn’t able to actually compile the plug-in, because there
are several GNU extensions used in GCC’s headers and in the plug-in
itself that are not supported (such as nested functions.)

One of the reasons why the feature test passes is that
‘clang -print-file-name=plugin’ returns GCC’s (!) header directory.

What do you think of having Clang error out instead, or perhaps return
the path to LLVM’s headers?

Thanks,
Ludo’.

Hello

One of the reasons why the feature test passes is that
‘clang -print-file-name=plugin’ returns GCC’s (!) header directory.

What is "GCC's header directory"? Will you please provide an example?
You mean the directory with your C / C++ std lib headers?

Hi,

Anton Korobeynikov <anton@korobeynikov.info> skribis:

Hello

One of the reasons why the feature test passes is that
‘clang -print-file-name=plugin’ returns GCC’s (!) header directory.

What is "GCC's header directory"? Will you please provide an example?

$ clang --version
clang version 3.0 (tags/RELEASE_30/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

$ ./result/bin/clang -print-file-name=plugin
/nix/store/k9lcfr49wdrad7j5p2pbiq2x0bmqd3pj-gcc-4.6.2/lib/gcc/x86_64-unknown-linux-gnu/4.6.2/plugin

$ gcc -print-file-name=plugin
/nix/store/32vc6sk2d4a3m88p821rxxwj83z7rf63-gcc-debug-4.6.2/lib/gcc/x86_64-unknown-linux-gnu/4.6.2/plugin

Thanks,
Ludo’.