Re: Trying to build gcc-python-plugin-0.9 on Debian unstable

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?