5:20 p.m.
Hi all,
(Please keep me Cc-ed, I'm not subscribed)
I'm trying to build the plugin, but I have lots of unittest failures,
like:
libcpychecker.compat.CouldNotFindVarDecl: could not find expected global
variable 'PyExc_TypeError'
It seems to me that this is
https://fedorahosted.org/gcc-python-plugin/ticket/21, as Debian has gcc
4.6.3 which probably includes the fix.
Any hint on how to workaround this issue? I've tried to build with
Debian's gcc-4.7, but I get into other issues (missing warning_at…).
thanks,
iustin
5:42 p.m.
On Tue, 2012-03-06 at 00:20 +0100, Iustin Pop wrote:
Hi all,
(Please keep me Cc-ed, I'm not subscribed)
I'm trying to build the plugin, but I have lots of unittest failures,
like:
libcpychecker.compat.CouldNotFindVarDecl: could not find expected global
variable 'PyExc_TypeError'
It seems to me that this is
https://fedorahosted.org/gcc-python-plugin/ticket/21, as Debian has gcc
4.6.3 which probably includes the fix.
I believe that your analysis is correct:
this looks like ticket 21. If
you're seeing that CouldNotFindVarDecl error, your gcc 4.6 probably has
the patch for PR debug/51410, and that makes it difficult for the plugin
to locate the variable.
Any hint on how to workaround this issue? I've tried to build
with
Debian's gcc-4.7, but I get into other issues (missing warning_at…).
gcc 4.7 is
probably the way to go here. Can you post the error you run
into?
Thanks
Dave
5:42 a.m.
On Mon, Mar 05, 2012 at 06:42:28PM -0500, David Malcolm wrote:
On Tue, 2012-03-06 at 00:20 +0100, Iustin Pop wrote:
> Hi all,
>
> (Please keep me Cc-ed, I'm not subscribed)
>
> I'm trying to build the plugin, but I have lots of unittest failures,
> like:
>
> libcpychecker.compat.CouldNotFindVarDecl: could not find expected global
> variable 'PyExc_TypeError'
>
> It seems to me that this is
> https://fedorahosted.org/gcc-python-plugin/ticket/21, as Debian has gcc
> 4.6.3 which probably includes the fix.
I believe that your analysis is correct: this looks like ticket 21. If
you're seeing that CouldNotFindVarDecl error, your gcc 4.6 probably has
the patch for PR debug/51410, and that makes it difficult for the plugin
to locate the variable.
OK, then it seems I should try to find an older gcc for debian, if I
can't get 4.7 to work.
> Any hint on how to workaround this issue? I've tried to
build with
> Debian's gcc-4.7, but I get into other issues (missing warning_at…).
gcc 4.7 is probably the way to go here. Can you post the error you
run
into?
Sure. Basically I did:
ln -sf /usr/bin/gcc-4.7 /usr/bin/gcc
(by the way, you hardcode gcc in lots of places, so you can't override
it simply via CC or GCC env. vars)
$ gcc --version
gcc (Debian 4.7.0~rc1-1) 4.7.0 20120302 (prerelease)
$ make clean
$ make plugin
python generate-config-h.py -o autogenerated-config.h --gcc=gcc
locating plugin directory for gcc...
/usr/lib/gcc/x86_64-linux-gnu/4.7/plugin
checking for gcc-plugin.h... found
checking whether plugin.def defines PLUGIN_FINISH_DECL... yes
writing autogenerated-config.h
…
gcc -I/usr/lib/gcc/x86_64-linux-gnu/4.7/plugin/include -fPIC
-fno-strict-aliasing -O2 -Wall -Werror -g -I/usr/include/python2.7
-I/usr/include/python2.7 -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2
-Wall -Wstrict-prototypes -g -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security
-L/usr/lib/python2.7/config -lpthread -ldl -lutil -lm -lpython2.7
-Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions -shared
gcc-python.o gcc-python-attribute.o gcc-python-callbacks.o
gcc-python-callgraph.o gcc-python-cfg.o gcc-python-closure.o
gcc-python-diagnostics.o gcc-python-function.o gcc-python-gimple.o
gcc-python-location.o gcc-python-option.o gcc-python-parameter.o
gcc-python-pass.o gcc-python-pretty-printer.o gcc-python-rtl.o
gcc-python-tree.o gcc-python-variable.o gcc-python-version.o
gcc-python-wrapper.o autogenerated-callgraph.o autogenerated-cfg.o
autogenerated-option.o autogenerated-function.o autogenerated-gimple.o
autogenerated-location.o autogenerated-parameter.o autogenerated-pass.o
autogenerated-pretty-printer.o autogenerated-rtl.o autogenerated-tree.o
autogenerated-variable.o -o python.so
However:
$ make
…
Stderr:
cc1: error: cannot load plugin /orchard/tmp/gcc-python-plugin-0.9/python.so
/orchard/tmp/gcc-python-plugin-0.9/python.so: undefined symbol: warning_at
And this repeats a lot; as far as I know, warning_at is an internal gcc
API, so it should be present. Maybe it's due to presence of both gcc 4.6
and 4.7 on the same system, and pointing just gcc to gcc-4.7 is not
enough?
FYI, ldd on python.so plugin is:
linux-vdso.so.1 => (0x00007fffcd3ff000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe105f66000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe105d62000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fe105b5e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe1058dc000)
libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x00007fe1053dd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe105055000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe10645e000)
libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
(0x00007fe104e03000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(0x00007fe104a3d000)
libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007fe104826000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe104610000)
So it does link against gcc_s.so…
When compiling against gcc-4.6, it doesn't break in this way, but I
don't know how to debug which library exports warning_at. The only thing
which I find surprising is:
$ objdump -T ./gcc/x86_64-linux-gnu/4.6/cc1|grep warning_at
000000000057d9f0 g DF .text 00000000000000be Base warning_at
but:
$ objdump -T ./gcc/x86_64-linux-gnu/4.7/cc1|grep warning_at
0000000000c27e10 g DF .text 00000000000000c2 Base _Z10warning_atjiPKcz
which looks like symbol mangling?
thanks,
iustin
11 a.m.
On Tue, 2012-03-06 at 12:42 +0100, Iustin Pop wrote:
On Mon, Mar 05, 2012 at 06:42:28PM -0500, David Malcolm wrote:
> On Tue, 2012-03-06 at 00:20 +0100, Iustin Pop wrote:
> > Hi all,
> >
> > (Please keep me Cc-ed, I'm not subscribed)
> >
> > I'm trying to build the plugin, but I have lots of unittest failures,
> > like:
> >
> > libcpychecker.compat.CouldNotFindVarDecl: could not find expected global
> > variable 'PyExc_TypeError'
> >
> > It seems to me that this is
> > https://fedorahosted.org/gcc-python-plugin/ticket/21, as Debian has gcc
> > 4.6.3 which probably includes the fix.
> I believe that your analysis is correct: this looks like ticket 21. If
> you're seeing that CouldNotFindVarDecl error, your gcc 4.6 probably has
> the patch for PR debug/51410, and that makes it difficult for the plugin
> to locate the variable.
OK, then it seems I should try to find an older gcc for debian, if I
can't get 4.7 to work.
> > Any hint on how to workaround this issue? I've tried to build with
> > Debian's gcc-4.7, but I get into other issues (missing warning_at…).
> gcc 4.7 is probably the way to go here. Can you post the error you run
> into?
Sure. Basically I did:
ln -sf /usr/bin/gcc-4.7 /usr/bin/gcc
(by the way, you hardcode gcc in lots of places, so you can't override
it simply via CC or GCC env. vars)
Ooops, sorry about that.
I've attempted to fix this as of
6efb53798d72efc38448d0332f7c32377c0c8029 so that it picks up on "GCC" in
the environment (I hope).
Does this work for you? Did I miss any places?
$ gcc --version
gcc (Debian 4.7.0~rc1-1) 4.7.0 20120302 (prerelease)
$ make clean
$ make plugin
python generate-config-h.py -o autogenerated-config.h --gcc=gcc
locating plugin directory for gcc...
/usr/lib/gcc/x86_64-linux-gnu/4.7/plugin
checking for gcc-plugin.h... found
checking whether plugin.def defines PLUGIN_FINISH_DECL... yes
writing autogenerated-config.h
…
gcc -I/usr/lib/gcc/x86_64-linux-gnu/4.7/plugin/include -fPIC
-fno-strict-aliasing -O2 -Wall -Werror -g -I/usr/include/python2.7
-I/usr/include/python2.7 -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2
-Wall -Wstrict-prototypes -g -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security
-L/usr/lib/python2.7/config -lpthread -ldl -lutil -lm -lpython2.7
-Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions -shared
gcc-python.o gcc-python-attribute.o gcc-python-callbacks.o
gcc-python-callgraph.o gcc-python-cfg.o gcc-python-closure.o
gcc-python-diagnostics.o gcc-python-function.o gcc-python-gimple.o
gcc-python-location.o gcc-python-option.o gcc-python-parameter.o
gcc-python-pass.o gcc-python-pretty-printer.o gcc-python-rtl.o
gcc-python-tree.o gcc-python-variable.o gcc-python-version.o
gcc-python-wrapper.o autogenerated-callgraph.o autogenerated-cfg.o
autogenerated-option.o autogenerated-function.o autogenerated-gimple.o
autogenerated-location.o autogenerated-parameter.o autogenerated-pass.o
autogenerated-pretty-printer.o autogenerated-rtl.o autogenerated-tree.o
autogenerated-variable.o -o python.so
OK, looks like it successfully built the plugin.
However:
$ make
…
Stderr:
cc1: error: cannot load plugin /orchard/tmp/gcc-python-plugin-0.9/python.so
/orchard/tmp/gcc-python-plugin-0.9/python.so: undefined symbol: warning_at
And this repeats a lot; as far as I know, warning_at is an internal gcc
API, so it should be present. Maybe it's due to presence of both gcc 4.6
and 4.7 on the same system, and pointing just gcc to gcc-4.7 is not
enough?
FYI, ldd on python.so plugin is:
linux-vdso.so.1 => (0x00007fffcd3ff000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe105f66000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe105d62000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fe105b5e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe1058dc000)
libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x00007fe1053dd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe105055000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe10645e000)
libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
(0x00007fe104e03000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(0x00007fe104a3d000)
libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007fe104826000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe104610000)
So it does link against gcc_s.so…
When compiling against gcc-4.6, it doesn't break in this way, but I
don't know how to debug which library exports warning_at. The only thing
which I find surprising is:
$ objdump -T ./gcc/x86_64-linux-gnu/4.6/cc1|grep warning_at
000000000057d9f0 g DF .text 00000000000000be Base warning_at
but:
$ objdump -T ./gcc/x86_64-linux-gnu/4.7/cc1|grep warning_at
0000000000c27e10 g DF .text 00000000000000c2 Base _Z10warning_atjiPKcz
which looks like symbol mangling?
Yes, that's C++ symbol mangling:
$ c++filt _Z10warning_atjiPKcz
warning_at(unsigned int, int, char const*, ...)
My guess is that that GCC 4.7 has been built using C++ and hence the
symbols have been mangled (and hence the dynamic link fails when the
plugin is loaded). Do any other GCC plugins work with it?
Dave
7:26 p.m.
On Tue, 2012-03-06 at 12:00 -0500, David Malcolm wrote:
[...snip...]
My guess is that that GCC 4.7 has been built using C++ and hence the
symbols have been mangled (and hence the dynamic link fails when the
plugin is loaded). Do any other GCC plugins work with it?
This would seem to be:
http://gcc.gnu.org/ml/gcc/2012-03/msg00116.html
4447
days inactive
4452
days old
gcc-python-plugin@lists.fedorahosted.org
4 comments
2 participants
participants (2)
-
David Malcolm -
Iustin Pop