Build errors
Simon Feltman
s.feltman@gmail.com
Tue Jan 1 00:00:00 GMT 2013
Hi,
I think this is an exciting project, many thanks! I am interested in
the potential to use pygccgit as a runtime Python binding generator
within PyGI (aka PyGObject3) but have hit a few initial snags.
I've attempted to build things following the wiki instructions and ran
into this error:
../../src/gcc/jit/internal-api.c:1479:21: error: ‘error’ was not
declared in this scope
I removed the offending line to see if it would continue and hit this:
make[4]: Entering directory
`/home/simon/projects/jit/build/x86_64-unknown-linux-gnu/32/libgcc'
make[4]: *** No rule to make target `all'. Stop.
make[4]: Leaving directory
`/home/simon/projects/jit/build/x86_64-unknown-linux-gnu/32/libgcc'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory
`/home/simon/projects/jit/build/x86_64-unknown-linux-gnu/libgcc'
make[2]: *** [all-multi] Error 2
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory
`/home/simon/projects/jit/build/x86_64-unknown-linux-gnu/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/home/simon/projects/jit/build'
make: *** [all] Error 2
However it looks like libgccjit.so was built after all, so I'm not
sure what the above make error is all about:
$ file gcc/libgccjit.so
gcc/libgccjit.so: ELF 64-bit LSB shared object, x86-64, version...
The pygccjit code on github was a bit stale so I updated it to match
the new "get_type" API with an enum arg and submitted a pull request.
But I'm now hitting this when running test.py:
$ python3 test.py
.libgccjit.so: internal compiler error: Segmentation fault
0x7fad42a2a0e6 crash_signal
../../src/gcc/toplev.c:336
0x7fad426c33c5 gcc::jit::function::add_conditional(gcc::jit::location*,
gcc::jit::rvalue*, gcc::jit::label*, gcc::jit::label*)
../../src/gcc/jit/internal-api.c:944
0x7fad436a04ba __pyx_pf_6gccjit_8Function_8add_conditional
/home/simon/projects/pygccjit/gccjit.c:3795
0x7fad436a04ba __pyx_pw_6gccjit_8Function_9add_conditional
/home/simon/projects/pygccjit/gccjit.c:3766
0x7fad4369f1d8 __pyx_f_6gccjit__c_callback
/home/simon/projects/pygccjit/gccjit.c:956
0x7fad426c2485 gcc::jit::context::invoke_code_factory()
../../src/gcc/jit/internal-api.c:1345
Some additional thoughts on pygccjit: In terms of API for the enums, I
think it would nice to follow more of a hierarchy. So instead of:
gccjit.FUNCTION_EXPORTED
It could be:
gccjit.FunctionKind.EXPORTED
I see that Result.get_code is already using ctypes internally but I
think it would be nice to add more public API parity, or even the
ability to use ctypes as the front end for building out initial
function signatures:
sig = ctypes.CFUNCTYPE(ctypes.c_int, ctypes.c_int)
fn = ctxt.new_function_from_ctypes("foo", sig)
or pull in a function symbol from ctypes for calling with in jit code:
incref = ctxt.import_function_from_ctypes(ctypes.pythonapi.Py_IncRef)
...
fn.add_function_call(incref, pyobj)
What do you think?
Thanks!
-Simon
More information about the Jit
mailing list