cffi-devel

cffi-devel@common-lisp.net

1113 discussions

How to load a dylib from a particular place
by Jim Newton 15 Sep '16

15 Sep '16

I sent this email earlier, but then realized I was not subscribed. So I have know way of knowing whether it got spam-filtered out. So here it is again. Sorry if this is a repeat question. The program I'm trying to load has several dependencies which I'm still trying to figure out. One problem (I think) is that it loading some of its .dylib libraries from the wrong place. I'd like to load them explicitly to help me debug the problem. What is the correct way to do this. Here's what I've tried (but it is not yet correct). I've added the line to my .sbclrc file. (cffi:load-foreign-library "/usr/local/Cellar/cairo/1. 12.16_1/lib/libcairo.dylib") This seems indeed to load the dylib, but later my system calls (CFFI::LOAD-FOREIGN-LIBRARY-PATH :LIBCAIRO "libcairo.dylib" NIL) which apparently does not realise :LIBCAIRO is already loaded, so it tries to load cairo again but from /usr/local/Cellar/cairo/1.14. 6_1/lib/libcairo.2.dylib Is there a way for me to tell cffi:load-foreign-library that loading 1.12.16_1 loads :LIBCAIRO ? I thought about calling cffi:define-foreign-library to associate :LIBCAIRO with the explicit path "/usr/local/Cellar/cairo/1.12.16_1/lib/libcairo.dylib", but I don't see how to do that. Can someone help? Thanks. Jim

2 1

Re: How to load a dylib from a particular place
by Jim Newton 15 Sep '16

15 Sep '16

When I read the documentation of DEFINE-FOREIGN-LIBRARY at https://common-lisp.net/project/cffi/manual/html_node/define_002dforeign_00… I don't see any way of defining a library and associating a full path. It really seems (and correct me if I'm wrong) that you can only specify paths in the case "if not found in system-global directories." But exactly what that means is not immediately clear. I assume it means that in all cases dload() will be called first, passing the library name, and if that fails, then cffi will attempt to find it elsewhere. What I'd like to do is circumvent dload() from being called because I know it will load the wrong file (wrong version). Am I reading the documentation wrong? Is there really a way to load the dylib from a specified directory and associate it with the lisp symbol for cffi's db? On Thu, Sep 15, 2016 at 11:24 AM, Jim Newton <jimka.issy(a)gmail.com> wrote: > The program I'm trying to load has several dependencies which I'm still > trying to figure out. > One problem (I think) is that it loading some of its .dylib libraries from > the wrong place. > I'd like to load them explicitly to help me debug the problem. > What is the correct way to do this. > > Here's what I've tried (but it is not yet correct). > I've added the line to my .sbclrc file. > > (cffi:load-foreign-library "/usr/local/Cellar/cairo/1. > 12.16_1/lib/libcairo.dylib") > > This seems indeed to load the dylib, but later my system > calls (CFFI::LOAD-FOREIGN-LIBRARY-PATH :LIBCAIRO "libcairo.dylib" NIL) > which apparently does not realise :LIBCAIRO is already loaded, so it > tries to load cairo again but from /usr/local/Cellar/cairo/1.14. > 6_1/lib/libcairo.2.dylib > > Is there a way for me to tell cffi:load-foreign-library that loading > 1.12.16_1 loads :LIBCAIRO ? > I thought about calling cffi:define-foreign-library to associate :LIBCAIRO > with the explicit path "/usr/local/Cellar/cairo/1.12.16_1/lib/libcairo.dylib", > but I don't see how to do that. > > Can someone help? > > Thanks. > Jim >

1 0

Re: Questions about cffi's c2ffi support
by Chris Bagley 12 Sep '16

12 Sep '16

Fantastic! Thanks for all your work on this feature. I love being able to jump to the definitions without have to dance with any macros once I'm there. I expect to be booked up for the next week or two but if I get time I'll look at expanding the grovel-caching branch I'm working on to cache the libffi type stuff. Cheers, Chris On 11 September 2016 at 22:39, Attila Lendvai <attila(a)lendvai.name> wrote: >>> When might I want to use this in place of cl-autowrap? >> >> cl-autowrap only uses the CFFI backends and replaces the surface API >> of CFFI with its own, and while it has interesting features, not >> everyone wants to depart from CFFI. >> >> in contrast to that cffi/c2ffi is a small thing that generates vanilla >> CFFI definitions. > > > this should really go into the doc, but meanwhile here are two > examples that use it: > > https://github.com/attila-lendvai/hu.dwim.sdl > https://github.com/attila-lendvai/hu.dwim.bluez > > -- > • attila lendvai > • PGP: 963F 5D5F 45C7 DFCD 0A39 > -- > “If you suffer it is because of you, if you feel blissful it is > because of you. Nobody else is responsible – only you and you alone. > You are your hell and your heaven too.” > — Osho (1931–1990)

1 0

Questions about cffi's c2ffi support
by Chris Bagley 11 Sep '16

11 Sep '16

Hi folks, I'm interested in the c2ffi portion of cffi and whether I can help. When might I want to use this in place of cl-autowrap? Are there open tasks for this feature? I saw the comments say that it is "not very extensive" what kinds of things are missing? Regards

2 2

Re: Would love some feedback on wip feature
by Chris Bagley 29 Aug '16

29 Aug '16

Ok I have made the changes we spoke about and I think it's in a place where we can start testing some projects with it. Find the latest at: https://github.com/cbaggers/cffi/tree/feature-grovel-caching Excited to hear your results/issues, Baggers On 29 August 2016 at 00:18, Chris Bagley <chris.bagley(a)gmail.com> wrote: > [sorry I keep replying to luis instead of the mailinglist] > >> but I think all we have to do is look at *features* really. > Yup and uiop has #'operating-system and #'architecture that helps us out there > >> Perhaps grabbing the #+/#- reader macro functions and invoking them directly is slightly more elegant/robust than calling going through read-from-string? > hmm could be, how would we get the feature-expression from those? > >> Which direction are we copying in, and is that .cache directory grovel's or ASDF's? > So in my branch currently: > - if we have the files cached we copy them to .cache > - if we dont have them cached we build them in .cache > > My chance would be to the 'dont have them case' > - if we dont have them cached we build them in .cache and then copy > the results to the cache folder > > On 29 August 2016 at 00:17, Chris Bagley <chris.bagley(a)gmail.com> wrote: >>> but I think all we have to do is look at *features* really. >> Yup and uiop has #'operating-system and #'architecture that helps us out there >> >>> Perhaps grabbing the #+/#- reader macro functions and invoking them directly is slightly more elegant/robust than calling going through read-from-string? >> hmm could be, how would we get the feature-expression from those? >> >>> Which direction are we copying in, and is that .cache directory grovel's or ASDF's? >> So in my branch currently: >> - if we have the files cached we copy them to .cache >> - if we dont have them cached we build them in .cache >> >> My chance would be to the 'dont have them case' >> - if we dont have them cached we build them in .cache and then copy >> the results to the cache folder >> >> On 28 August 2016 at 22:21, Luís Oliveira <luismbo(a)gmail.com> wrote: >>> [cc-ing cffi-devel] >>> >>> On Sun, Aug 28, 2016 at 8:08 PM, Chris Bagley <chris.bagley(a)gmail.com> wrote: >>>> Cool, thanks for the details and sorry I've been busy this last week. >>>> >>>>> cpu/vendor/os triplet >>>> >>>> Sounds like it would be good to include these by default in the >>>> feature check, I'll add that. >>> >>> At first I was worried we'd need to check this via uname or something >>> and that'd we need to handle the special case of running a 32-bit Lisp >>> on a 64-bit OS and things like that, but I think all we have to do is >>> look at *features* really. >>> >>> >>>>> dirty-featurep is not super pretty but it seems like the way to go >>>> >>>> Cool, then I will move this into cffi itself, and leave my potentially >>>> less portable version in the with-cached-reader-conditionals library >>> >>> Perhaps grabbing the #+/#- reader macro functions and invoking them >>> directly is slightly more elegant/robust than calling going through >>> read-from-string? >>> >>> >>>>> Windows is picky about what a valid pathname is and (b) it's got a 260 character limit for pathnames. >>>> >>>> 100% agreed, also symbols can be unicode so that would break fast. >>>> >>>>> Perhaps we just need to record the result of each reader conditional, store those boolean results as increasingly significant bits in an integer >>>> >>>> The case I was worried about there is say someone had the following in >>>> their spec file: >>>> >>>> (and linux swank (not windows)) >>>> >>>> And that was #b110 >>>> >>>> And they change it to: >>>> >>>> (and linux sly (not windows)) >>>> >>>> And that would still be #b110. >>>> >>>> I think we should do what you said about appending to the triplet but >>>> we should use some simple string hashing function instead of the >>>> bitmask. Will be a little ugly but robust at least. >>> >>> Good point. Hashing seems much more reasonable than my suggestion. :-) >>> >>> >>>>> Can we avoid the copying by just writing to and loading from the cache directory unconditionally? >>>> >>>> Good question. I liked asdf's rational for using the system's cache >>>> directory for fasls and intermediate files and like how cffi uses it >>>> too. I'm a bit nervous of someone trying to use asdf to load a >>>> grovelling library from a directory they don't have write permissions >>>> for as currently that works fine. >>>> >>>> Actually, we could just check: if we have write permission we copy >>>> unconditionally, if not then we just leave it in the .cache dir. >>> >>> Complying with ASDF's concept of output/cache directory does seem >>> important. (Perhaps we could ask asdf-devel for advice?) But I didn't >>> grasp this last solution you've suggested. Which direction are we >>> copying in, and is that .cache directory grovel's or ASDF's? >>> >>>> >>>> I'll get implementing the above. Feel free to throw more ideas in the pile! >>>> >>>> Baggers >>> >>> Cheers, >>> >>> -- >>> Luís Oliveira >>> http://kerno.org/~luis/

1 0

Re: Would love some feedback on wip feature
by Chris Bagley 29 Aug '16

29 Aug '16

[sorry I keep replying to luis instead of the mailinglist] > but I think all we have to do is look at *features* really. Yup and uiop has #'operating-system and #'architecture that helps us out there > Perhaps grabbing the #+/#- reader macro functions and invoking them directly is slightly more elegant/robust than calling going through read-from-string? hmm could be, how would we get the feature-expression from those? > Which direction are we copying in, and is that .cache directory grovel's or ASDF's? So in my branch currently: - if we have the files cached we copy them to .cache - if we dont have them cached we build them in .cache My chance would be to the 'dont have them case' - if we dont have them cached we build them in .cache and then copy the results to the cache folder On 29 August 2016 at 00:17, Chris Bagley <chris.bagley(a)gmail.com> wrote: >> but I think all we have to do is look at *features* really. > Yup and uiop has #'operating-system and #'architecture that helps us out there > >> Perhaps grabbing the #+/#- reader macro functions and invoking them directly is slightly more elegant/robust than calling going through read-from-string? > hmm could be, how would we get the feature-expression from those? > >> Which direction are we copying in, and is that .cache directory grovel's or ASDF's? > So in my branch currently: > - if we have the files cached we copy them to .cache > - if we dont have them cached we build them in .cache > > My chance would be to the 'dont have them case' > - if we dont have them cached we build them in .cache and then copy > the results to the cache folder > > On 28 August 2016 at 22:21, Luís Oliveira <luismbo(a)gmail.com> wrote: >> [cc-ing cffi-devel] >> >> On Sun, Aug 28, 2016 at 8:08 PM, Chris Bagley <chris.bagley(a)gmail.com> wrote: >>> Cool, thanks for the details and sorry I've been busy this last week. >>> >>>> cpu/vendor/os triplet >>> >>> Sounds like it would be good to include these by default in the >>> feature check, I'll add that. >> >> At first I was worried we'd need to check this via uname or something >> and that'd we need to handle the special case of running a 32-bit Lisp >> on a 64-bit OS and things like that, but I think all we have to do is >> look at *features* really. >> >> >>>> dirty-featurep is not super pretty but it seems like the way to go >>> >>> Cool, then I will move this into cffi itself, and leave my potentially >>> less portable version in the with-cached-reader-conditionals library >> >> Perhaps grabbing the #+/#- reader macro functions and invoking them >> directly is slightly more elegant/robust than calling going through >> read-from-string? >> >> >>>> Windows is picky about what a valid pathname is and (b) it's got a 260 character limit for pathnames. >>> >>> 100% agreed, also symbols can be unicode so that would break fast. >>> >>>> Perhaps we just need to record the result of each reader conditional, store those boolean results as increasingly significant bits in an integer >>> >>> The case I was worried about there is say someone had the following in >>> their spec file: >>> >>> (and linux swank (not windows)) >>> >>> And that was #b110 >>> >>> And they change it to: >>> >>> (and linux sly (not windows)) >>> >>> And that would still be #b110. >>> >>> I think we should do what you said about appending to the triplet but >>> we should use some simple string hashing function instead of the >>> bitmask. Will be a little ugly but robust at least. >> >> Good point. Hashing seems much more reasonable than my suggestion. :-) >> >> >>>> Can we avoid the copying by just writing to and loading from the cache directory unconditionally? >>> >>> Good question. I liked asdf's rational for using the system's cache >>> directory for fasls and intermediate files and like how cffi uses it >>> too. I'm a bit nervous of someone trying to use asdf to load a >>> grovelling library from a directory they don't have write permissions >>> for as currently that works fine. >>> >>> Actually, we could just check: if we have write permission we copy >>> unconditionally, if not then we just leave it in the .cache dir. >> >> Complying with ASDF's concept of output/cache directory does seem >> important. (Perhaps we could ask asdf-devel for advice?) But I didn't >> grasp this last solution you've suggested. Which direction are we >> copying in, and is that .cache directory grovel's or ASDF's? >> >>> >>> I'll get implementing the above. Feel free to throw more ideas in the pile! >>> >>> Baggers >> >> Cheers, >> >> -- >> Luís Oliveira >> http://kerno.org/~luis/

1 0

Re: Would love some feedback on wip feature
by Luís Oliveira 28 Aug '16

28 Aug '16

[cc-ing cffi-devel] On Sun, Aug 28, 2016 at 8:08 PM, Chris Bagley <chris.bagley(a)gmail.com> wrote: > Cool, thanks for the details and sorry I've been busy this last week. > >> cpu/vendor/os triplet > > Sounds like it would be good to include these by default in the > feature check, I'll add that. At first I was worried we'd need to check this via uname or something and that'd we need to handle the special case of running a 32-bit Lisp on a 64-bit OS and things like that, but I think all we have to do is look at *features* really. >> dirty-featurep is not super pretty but it seems like the way to go > > Cool, then I will move this into cffi itself, and leave my potentially > less portable version in the with-cached-reader-conditionals library Perhaps grabbing the #+/#- reader macro functions and invoking them directly is slightly more elegant/robust than calling going through read-from-string? >> Windows is picky about what a valid pathname is and (b) it's got a 260 character limit for pathnames. > > 100% agreed, also symbols can be unicode so that would break fast. > >> Perhaps we just need to record the result of each reader conditional, store those boolean results as increasingly significant bits in an integer > > The case I was worried about there is say someone had the following in > their spec file: > > (and linux swank (not windows)) > > And that was #b110 > > And they change it to: > > (and linux sly (not windows)) > > And that would still be #b110. > > I think we should do what you said about appending to the triplet but > we should use some simple string hashing function instead of the > bitmask. Will be a little ugly but robust at least. Good point. Hashing seems much more reasonable than my suggestion. :-) >> Can we avoid the copying by just writing to and loading from the cache directory unconditionally? > > Good question. I liked asdf's rational for using the system's cache > directory for fasls and intermediate files and like how cffi uses it > too. I'm a bit nervous of someone trying to use asdf to load a > grovelling library from a directory they don't have write permissions > for as currently that works fine. > > Actually, we could just check: if we have write permission we copy > unconditionally, if not then we just leave it in the .cache dir. Complying with ASDF's concept of output/cache directory does seem important. (Perhaps we could ask asdf-devel for advice?) But I didn't grasp this last solution you've suggested. Which direction are we copying in, and is that .cache directory grovel's or ASDF's? > > I'll get implementing the above. Feel free to throw more ideas in the pile! > > Baggers Cheers, -- Luís Oliveira http://kerno.org/~luis/

1 0

CFFI load-foreign-library problem
by Marco Antoniotti 14 Jun '16

14 Jun '16

Hi sorry for the noise… I have gotten confused (among other things) about the status of CFFI’s mailing lists. In any case, I have the following problem. This is in my "test" file: (cffi:define-foreign-library cl-autowrap-tests-lib (t "cl-autowrap-test.a")) This is what I get on LWM. CL-USER 15 > (cffi:load-foreign-library 'cl-autowrap-tests::cl-autowrap-tests-lib) Error: Unable to load foreign library (CL-AUTOWRAP-TESTS-LIB). Could not register handle for external module CL-AUTOWRAP-TESTS::CL-AUTOWRAP-TESTS-LIB: no suitable image found. Did find: /Users/marcoxa/Projects/Lang/CL/tests/cl-autowrap/cl-autowrap-test.a: file too short. 1 (continue) Try loading the foreign library again. 2 Use another library instead. 3 (abort) Return to level 0. 4 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. It obviously appears that something may be amiss with the .a (static) generation. My C/C++ fu us very rusty. Any ideas? Cheers -- MA -- Marco Antoniotti

2 3

test
by Marco Antoniotti 13 Jun '16

13 Jun '16

Just ignore... -- Marco Antoniotti

1 0

added a wiki page for cffi/c-stdlib system
by Attila Lendvai 18 Apr '16

18 Apr '16

https://github.com/cffi/cffi/wiki/Proposal-for-a-CFFI-C-STDLIB-system -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Have the courage to take your own thoughts seriously, for they will shape you.” — Albert Einstein (1879–1955)

1 0

← Newer
1
2
3
4
5
6
7
8
...
112
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel