Messages in this thread | | | Date | Fri, 26 Feb 2016 15:38:09 -0500 | Subject | perf install-python_ext installing .o files in python site-packages | From | Josh Boyer <> |
| |
Hi Arnaldo,
We've had a report [1] that the python-perf package in Fedora installs a handful of .o files in /usr/lib64/python2.7/site-packages/. This is true on Linus' latest tree, but it goes back to arriving with the 4.2 kernel.
Digging around a bit, it seems the files installed are those that are found as relative paths in the utils/python-ext-sources directory:
/usr/lib64/python2.7/site-packages/bitmap.o /usr/lib64/python2.7/site-packages/find_bit.o /usr/lib64/python2.7/site-packages/hweight.o /usr/lib64/python2.7/site-packages/rbtree.o
None of those files should really be installed at all, as they're temporary object files used to build perf.so.
As far as I can tell, this is a side effect of using the python distutils module with it's setup.py script. The sources are listed there so they get included, but then the build_ext functionality interprets it as e.g.:
-c ../lib/hweight.c -o python_ext_build/tmp/../lib/hweight.o
That leaves it in the lib/ directory of the build output alongside the final perf.so instead of python_ext_build/tmp/util/ like the rest of the object files. It happens to be an unfortunate coincidence that install-lib looks in said .../lib/ directory and we just happen to conflict with that naming. So when install-python_ext is called, it simply copies everything in that directory, including the .o files.
I'm not enough of a python wizard to figure out how to fix this quickly. We could remove the .o files in the .spec file, but that seems hacky and this should probably be fixed in the perf build system.
Ideas?
josh
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1312102
| |