On Tue, 2012-11-06 at 15:25 -0500, David Malcolm wrote:
On Tue, 2012-11-06 at 21:12 +0100, Klaus Rudolph wrote:
[...]
> >> Hard to find an entry point :-)
> >
> > insn_file is not an entry point - the plugin entry point is
> > plugin_init in plugin.c
> >
>
> :-) I search an entry point for *me* to parse c++ files, not an entry
> point of the compiler :-)
This is probably yet another symptom of an issue we're seeing with
recent builds of gcc 4.7 that have been built with C++, rather than with
C - the symbols that the plugin needs may have been name-mangled if gcc
was built with C++. I've recently committed various fixes for this.
If you look at:
eu-readelf -s $(which gcc) | less
is it full of things with "_Z"? (e.g. "_Z10warning_atjiPKcz") If
so,
then your GCC was built with a C++ compiler, and running:
make clean && make CC=g++
may help; I'm working on a fix to autodetect this.
Committed as:
http://git.fedorahosted.org/cgit/gcc-python-plugin.git/commit/?id=0ff8879...
Please test and see if it works on your GCC! (you'll need to do a "make
clean" of the plugin first).
[...]
Out of interest, what's the output of:
grep ENABLE_BUILD_WITH_CXX $(PATH_TO_YOUR_GCC
--print-file-name=plugin)/include/auto-host.h
(this is what I'm looking at for the autodetection logic, based on
http://gcc.gnu.org/ml/gcc/2012-03/msg00411.html, although
ENABLE_BUILD_WITH_CXX seems to only be present on 4.6 and 4.7, and
appears to have gone away entirely in 4.8, which uses C++-only features
internally).
^^^^ this is what the above commit tries to use.
Dave