Thanks Armin. Yes __del__ fits my case and thanks for giving me so much
information.
Thanks,
-Roshan
On Tue, Sep 22, 2015 at 2:05 AM, Armin Rigo wrote:
> Hi Roshan,
>
> On Mon, Sep 21, 2015 at 9:58 PM, Roshan Cherian
> wrote:
> > I do have a question on memory management, currently I am using
Hi Roshan,
On Mon, Sep 21, 2015 at 9:58 PM, Roshan Cherian wrote:
> I do have a question on memory management, currently I am using lib.
> Currently lib provides me with icalcomponent_free which I pass in as the
> function to be used in __del__. Should I be using this or should I be using
> somet
Thanks Armin and Maciej. I now have the code running on a box without gcc
on it and I don't use ffi.dlopen, I now distribute the generated
_ical_cffi_ext.c which was generated using ffi.compile() and use distuitils
to build it to site-packges of pypy. Thanks a lot for this.
I do have a question on
Hi Roshan,
On Fri, Sep 18, 2015 at 10:02 AM, Roshan Cherian wrote:
> _icaltimezonechange is opaque as its in src/libical/icaltimezone.c a c file
> and not in in ical.h. However this struct is required for my purpose.
All structs must be declared in C before you import them into Python.
In this c
Hi Roshan,
On Tue, Sep 15, 2015 at 5:01 PM, Roshan Cherian wrote:
> libical = ffi.dlopen(ctypes.util.find_library('ical'))
> libical.ical_set_unknown_token_handling_setting(libical.ICAL_ASSUME_IANA_TOKEN)
>
> I get an error: AttributeError: ical_set_unknown_token_handling_setting
This me
Thanks Armin and Maciej.
Thanks for replying, let me share my case I have libical.so built into a
path which is set in LD_LIBRARY_PATH.
I have upgraded to pypy2.6.1 with libffi3.2.1 and cffi 1.2.1. I have run
the following:
>export LD_LIBRARY_PATH=./lib
>./pypy/bin/pypy>>
from cffi import FFI
ff
Hi Roshan,
On Tue, Sep 15, 2015 at 8:02 AM, Maciej Fijalkowski wrote:
> ffi.dlopen does not require a C compiler, ffi.verify does (which we
> strongly encourage to use). Note that since cffi 1.0 you only require
> C compiler to create extensions, you can distribute them without a
> compiler. See
ffi.dlopen does not require a C compiler, ffi.verify does (which we
strongly encourage to use). Note that since cffi 1.0 you only require
C compiler to create extensions, you can distribute them without a
compiler. See documentation for details
On Tue, Sep 15, 2015 at 5:39 AM, Roshan Cherian wrot
Hi Team,
I am not sure if I should be asking the question here, however hoping
someone could help.
we use ffi.cdef for definitions and ffi.dlopen to open shared library. To
my understanding ffi.dlopen only works in the presence of a c compiler to
dynamically link the shared lib. We have a linux b
Great thanks for all your help!
We found out the lib was lack of linking with some necessary libs.
By adding those depdent libs, dlopen is able to open the lib.
On Thu, Jul 9, 2015 at 3:53 AM, Yury V. Zaytsev wrote:
> On Wed, 2015-07-08 at 18:03 +0800, Yicong Huang wrote:
> >
> > With C code, it
On Wed, 2015-07-08 at 18:03 +0800, Yicong Huang wrote:
>
> With C code, it also reported that " undefined symbol:
> _ZTIN6apsara13ExceptionBaseE".
You should link distcache.so to the aspara library if you use any of its
symbols. For the details, you have to talk to your local specialist on
Aliba
Hi Yicong,
On 8 July 2015 at 12:03, Yicong Huang wrote:
> With C code, it also reported that " undefined symbol:
> _ZTIN6apsara13ExceptionBaseE".
It seems that "_distcache" cannot be used as you compiled it. The
problem is not related to cffi, nor PyPy nor Python. You should look
elsewhere for
How to use ffi.verfiy() to open a shared library?
I tried a C code by using dlopen, but met the same errors.
void *handle;
handle = dlopen("./_distcache.so", RTLD_LAZY);
if (!handle) {
fprintf(stderr, "%s\n", dlerror());
exit(EXIT_FAILURE);
}
With C code, it also reported that
Hi Maciej,
On 8 July 2015 at 11:14, Maciej Fijalkowski wrote:
> you should probably use verify instead of dlopen. This symbol is
> likely defined in libstdc++, which is not loaded in pypy (you might
> try to load it by hand, but I'm way out of my depth here)
http://demangler.com/ says the symbol
you should probably use verify instead of dlopen. This symbol is
likely defined in libstdc++, which is not loaded in pypy (you might
try to load it by hand, but I'm way out of my depth here)
On Wed, Jul 8, 2015 at 11:09 AM, Yicong Huang wrote:
> Hi,
>
> We tried to use cffi dlopen to load a C sha
Hi,
We tried to use cffi dlopen to load a C shared library.
However, we met the below error message:
Traceback (most recent call last):
File "/app_main.py", line 75, in run_toplevel
File "distcache.py", line 19, in
_distcache = ffi.dlopen("./_distcache.so")
File "/usr/ali/odps-pypy/lib_
16 matches
Mail list logo
