Dave, thanks for the advice.
That file was very helpful; I got the plugin to build on my machine. Unfortunately,
there are some problems; the plugin works on the examples: show-passes, show-callgraph,
and show-docs only. Show-ssa, show-gimple, and the libcpychecker all give seg faults.
These seg faults occur regardless of the c code being compiled (I tried several different
c programs including one that just prints hello world). For gcc-with python, when I
compile the same c code without the plugin (using macports gcc 4.6), I get no errors or
warnings. When I built python.so, there were no errors or warnings either. However, when
the object files were made, there were a lot of warnings. Additionally, I'm not sure
if my usage of libcpychecker was right: I used: ./gcc-with-cpychecker input.c script.py (I
took some example code and put it into the main plugin directory).
Here are some other things I had to change to build the plugin in addition to the changes
listed on the file you sent me:
Needs python 2.7 (uses argparse etc.)
gcc-with-python needed to be changed to: gcc-mp-4.6 -fplugin=python.so
-fplugin-arg-python-script=$@
gcc-python-docs needed to be changed to: ./gcc-with-python examples/show-docs.py test.c
You need to have fmemopen.o pre-made: the header and c source I used is available here:
http://code.google.com/p/python-tesseract/source/browse/wiki/python-tesse...
In the Makefile, the command to build the plugin needs to include fmemopen.o (I got a
linking error when I didn't)
The Makefile should have fmemopen.c in the source files
Also in the Makefile: Python.framework/Versions/2.7/Python does not exist; it should be
changed to: /Library/Frameworks/Python.framework/Versions/2.7/Python. I also needed to
leave out the arch commands to build it. The full command to build the plugin (python.so)
should look like:
gcc-mp-4.6 -I/opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.3/plugin/include -fPIC
-fno-strict-aliasing -O2 -Wall -g
-I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
-I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -fno-strict-aliasing
-fno-common -dynamic -isysroot /Developer/SDKs/MacOSX10.6.sdk -g -O2 -DNDEBUG -g -O3
-L/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config -ldl -framework
CoreFoundation -lpython2.7 -u _PyMac_Error
/Library/Frameworks/Python.framework/Versions/2.7/Python -undefined dynamic_lookup -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 util-fmemopen.o fmemopen.o -o python.so
I needed to have all the .def files in the directory with the plugin (this may just be
something wrong with the macports gcc 4.6).
If you want a full copy of the Makefile I used to build the plugin, please let me know.
When I run the Makefile, it does not build the test-suite because of the seg faults. I
think the problem is in the c source for the plugin because both libcpychecker and
gcc-with-python give seg faults (maybe fmemopen problems). I will continue working on
the seg fault problem. Do you have any ideas about how to fix the seg faults? At some
point, would you want me to make a Mac OSX install package for the plugin?
Nick
On Mar 21, 2012, at 9:22 PM, David Malcolm wrote:
On Wed, 2012-03-21 at 17:01 -0400, Nicholas Pasternack wrote:
Hi Nicholas
I've added comments inline below throughout.
> The following header does not work on all UNIX machines or machines
> running multiple versions of python: #include <Python.h>
>
> Depending on what version of Python you use, the header needs to
> change to: #include <python(version).(release)/Python.h> For
> instance, if you have python 2.7, the include line should read:
> #include <python2.7/Python.h>
The line:
#include <Python.h>
is the standard idiom for including the C Python extension API.
Locating the correct path for the header files (with the correct
version) is done using compiler options.
Normally this is done for gcc by passing a -I argument to the compiler.
For example, -I/usr/include/python2.7
You can determine the correct build flags by invoking
python-config --cflags
On my machine, this emits:
-I/usr/include/python2.7 -I/usr/include/python2.7 -fno-strict-aliasing
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC
-fwrapv
The Makefile tries to do this to extract these arguments, and it uses
the variable PYTHON_CONFIG so that this can be overridden if you have
multiple pythons installed. There may be bugs, of course.
> To the best of my knowledge, there are no Macros from the gcc that
> define the Python version the user is running. However, I know the
> following will be compatible with Mac computers:
>
> #ifdef __APPLE__
> #include <python2.6/Python.h>
> #else
> #include <Python.h>
> #endif
Are you trying to get the code to run on an OS X box? Some of us spent
some time at PyCon trying to get the code to build on such a machine.
I'm attaching the (very hacky) patch that eventually got the thing to
build, using the MacPorts build of gcc 4.6 (thanks to Daniel Lepage).
It would be good to get this cleaned up and merged.
Areas of pain we ran into:
* the plugin's code uses "fmemopen" in a few places, which doesn't
exist on OS X (we took some code from SCF as a quick and dirty way to
get the code to run [1]; we've approached that project for permission to
copy and relicense, but it's probably fairly easy to reimplement)
* IIRC the:
__typeof__ (decl_as_string) decl_as_string __attribute__ ((weak))
stuff that we do didn't work, so we simply disabled it for now
* the change to tests/cpychecker/Py_BuildValue/code_d/correct/input.c
is an OS X artifact: the filesystem is case-preserving but not
case-sensitive, so code_d/* and code_D/* cannot coexist. On git
checkout, one of them overwrites the other (and this seriously confuses
git)
> I think there should be a short explanatory note in the README
> describing how to change the include line; if the user has multiple
> versions of Python, the code will not compile unless you specifically
> state what version of Python to use in the include line.
The README.rst doesn't cover this, but docs/basics.rst does.
Hope this is helpful
Dave
[1]
<
https://redmine.openinfosecfoundation.org/attachments/105/0001-fmemopen-w...
>
<os-x.diff>_______________________________________________
gcc-python-plugin mailing list
gcc-python-plugin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/gcc-python-plugin