On June 22, 2015 10:17:24 AM CDT, Derek Lockhart <lockh...@csl.cornell.edu> wrote: >After a bit of a struggle I finally got RFFI working for a shared >libary I >had compiled. I found a few strange discrepancies in the behavior of >ExternalCompilitionInfo on OSX I thought may benefit from fixes to make >behavior more consistent. > >=== RPython Translation vs. Python Execution Strangeness === > >Given a shared library I had compiled named libsoftfloat.so: > >- ExternalCompilationInfo( libraries = ['libsoftfloat'] ) and libname >== >libsoftfloat.so > - python execution: Error: "cannot find library libsoftfloat" >- rpython translation: Error: "ld: library not found for >-llibsoftfloat" > >- ExternalCompilationInfo( libraries = ['softfloat'] ) and libname == >libsoftfloat.so > - python execution: Error: "cannot find library softfloat" > - rpython translation: Works! > >The problem with RFFI during Python execution appears to be that on OSX >it >checks for the library suffix of .dylib, **not** .so: > >- ExternalCompilationInfo( libraries = ['libsoftfloat'] ) and libname >== >libsoftfloat.dylib > - python execution: Works! >- rpython translation: Error: "ld: library not found for >-llibsoftfloat" > >- ExternalCompilationInfo( libraries = ['softfloat'] ) and libname == >libsoftfloat.dylib > - python execution: Works! > - rpython translation: Works! > >Some naming schemes work on just python execution, some on just rpython >translation. It would be nice if these failed/worked consistently in >both >modes. In particular, I think on OSX the library lookup for RFFI >should >look for both .so and .dylib, not just .dylib since it seems to be >fairly >common practice to generate .so files? > >Also, the libraries naming convention passed to ExternalCompilationInfo >is >a bit inconsistent/foreign for someone coming from CFFI and using >ffi.dlopen(). > >=== Documentation === > >I really couldn't figure out how to use RFFI from the RPython docs or >from >the PyPy source. I started off using these resources: > >- https://rpython.readthedocs.org/en/latest/rffi.html >- https://bitbucket.org/pypy/pypy/src/tip/rpython/rlib/_rsocket_rffi.py >- >https://bitbucket.org/pypy/pypy/src/tip/pypy/module/crypt/interp_crypt.py
I've been meaning to write a RFFI blog post for a bit now. IMO, the best learning resource is rlib: do a grep for 'rffi' in rpython/rlib and look at the referenced files. Another handy example was a PortAudio wrapper for RPython (I believe it was called rpyportaudio?). > >The only way I really figured out how to use it was from this patch >submitted by the libgccjit guy that had some simple examples on how to >use >RFFI: > >- https://mail.python.org/pipermail/pypy-dev/2014-December/012947.html > >What would be really nice is some example of how to write a simple >function >in C, compile it into a shared library, and use it via RFFI. Even >better, >an example mapping a CFFI use case to the RFFI interface. I personally >learn how to use APIs much more easily with concrete examples; for >example, >I created a little git repo as a self-demonstration of how to use the >new >CFFI APIs with a non-trivial library: > >- https://github.com/dmlockhart/python-softfloat-cffi/ > >I'd be willing to help a bit with the docs, if it's agreed updates >would be >appreciated. > >Derek > > >------------------------------------------------------------------------ > >_______________________________________________ >pypy-dev mailing list >pypy-dev@python.org >https://mail.python.org/mailman/listinfo/pypy-dev -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
