Hi Derek,
On 22 June 2015 at 17:17, Derek Lockhart <[email protected]> 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.
Before translation, we use a horrible hack to access the library for
tests, in rpython/rtyper/lltypesystem/ll2ctypes.py. The logic so far:
libpath = None
ext = platform.so_ext # <- this is where ".dylib"
comes from on OS/X
prefixes = platform.so_prefixes # <- on OS/X this is ('',)
for dir in eci.library_dirs:
if libpath:
break
for prefix in prefixes:
tryfile = os.path.join(dir, prefix + libname + '.' + ext)
if os.path.isfile(tryfile):
libpath = tryfile
break
if not libpath:
libpath = ctypes.util.find_library(libname) # <-
magic from ctypes
if not libpath:
libpath = _findLib_gcc_fallback(libname) # <-
magic from us
if not libpath and os.path.isabs(libname):
libpath = libname
if libpath:
<here, we have found the library to be in libpath>
This is meant to emulate what will occur after translation to C, but
is obviously approximate. I'm guessing that 'libsoftfloat' is found
here (but not after translation) because of
ctypes.util.find_library(). And I'm guessing that the code above only
looks for '.dylib' simply because that's platform.so_ext so far. I
fear that I cannot blindly change this logic and expect it to work
better. At this point it's up to you to try to tweak it for OS/X and
propose a patch.
> === Documentation ===
> (...)
> 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 suppose the very best would be for us to deprecate RFFI and replace
it with CFFI...
A bientôt,
Armin.
_______________________________________________
pypy-dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/pypy-dev
