To further expand on the strangeness, when using my libsoftfloat.dylib file
and trying to create getters/setters to an internal variable
using rffi.CExternVariable, I get the following error:
File
"/Users/dmlockhart/vc/hg-opensource/pypy/rpython/rtyper/lltypesystem/ll2ctypes.py",
line 1169, in get_ctypes_callable
clib = dllclass._dlltype(libpath, **load_library_kwargs)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py",
line 365, in __init__
self._handle = _dlopen(self._name, mode)
OSError:
dlopen(/var/folders/y4/c0cyz0bx6bjg5lzyd5prllbh0000gn/T/usession-default-109/shared_cache/externmod.dylib,
6): Library not loaded: libsoftfloat.so
Referenced from:
/var/folders/y4/c0cyz0bx6bjg5lzyd5prllbh0000gn/T/usession-default-109/shared_cache/externmod.dylib
Reason: image not found
So using rffi.llexternal expects a .dylib file on OSX, but
rffi.CExternVariable expects a .so file.
Creating a copy of the .dylib file so I have **both** a .so and .dylib file
makes this error go away; but I suspect internal state of the library would
not be consistent with two copies...
On Mon, Jun 22, 2015 at 11:17 AM, 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
>
> 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
