GCC compatibility layer going too far?

Clang Frontend
#1

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’.

#2

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?

#3

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’.