Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=588941 --- Comment #20 from Maciej Fijalkowski <fijall@xxxxxxxxx> 2010-11-29 13:02:01 EST --- (In reply to comment #19) Hi, will write down responses bit by bit :) > Maciej, thanks! > > Your tips will aid in figuring out what to do with CFLAGS. Very useful! Do > you happen to know if some of our CFLAGS are safe and useful to use with pypy? > Do you know which CFLAGS, like -fstack-protector are not needed with the > checking that pypy does itself? If you don't know I'll experiment a bit to see > what we can come up with. Essentially all -f flags that make gcc output different assembler (except those which are in Makefile by default like -fomit-frame-pointer) are likely to cause trouble. Those are two categories: * performance - likely pointless because we're generating our own assembler for hot places * security (like -fstack-protector) which I think are also pointless, because we're generating fairly straightforward C, which has additional checks for such things like stack depth. > > About the files that get installed on the filesystem, I cheated and just looked > at what ended up in the Linux binary package that is downloaded from pypy.org. > A few questions: > > * I see that you have some include files in the binary distribution but no > compiled shared library. What are the header files for? Should we be > packaging them? Those are for building your own C extensions with PyPy. They're somehow required for this to work, but the development status of this feature is alpha at best (I have a bit no clue how they'll work installed in some place). > * My understanding is that pypy can support compiled modules as well as pure > python modules. If that's the case, where does pypy search for them? We're > presently installing all of the pypy stdlib into > /usr/share/pypy-1.4/{lib-python,pypy_lib} which dmalcolm says is being > searched by pypy. But if there's compiled modules, at least those modules need > to land in /usr/lib/pypy-1.4 and /usr/lib64/pypy-1.4 (on 64bit multilib arches > like x86_64). Does pypy search these places by default similar to cpython does > or will we need to do some work on that? With cpython we have a split > site-packages such that /usr/lib/python2.5/site-packages is where we install > arch independent files (pure python modules and their byte compiled cache) and > (on x86_64), /usr/lib64/python2.5/site-packages is where we install the modules > with compiled code. PyPy has a very similar scheme where it looks for modules as CPython. Main difference is lib_pypy/lib-python, but besides it's almost identical. Note that PyPy implements PEP3149 which means that files will have unique names among versions (containing string pypy and 14), so there is no clash with other versions. That said, since this feature is anyway alpha, I find it very unlikely that someone will get a working module and install it somewhere, so for 1.4 it's a bit irrelevant. Cheers, fijal -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review