I seemed to have been mistaken the other day in my haste to get to work on-time, It seems I'm still getting
LCB Error unable to load foreign library
Object card id 1002
LCB File fluidsynthlib.lcb
LCB Line 17 <-- which is the 1st public handler that calls for loading the library
I believe Monte is on Mac OS X and was having similar problems trying to get version info from function in libYAML?
I'm wonder if any other Mac user has gotten a foreign lib to load at all ?
I think I'm just going to put this aside and go back to playing with widgets until LCB + foreign code is more complete, it's documentation exists, and my understanding of both is more mature.
Foreign Handlers and Custom Types
-
- Posts: 616
- Joined: Wed Apr 24, 2013 4:53 pm
- Contact:
Re: Foreign Handlers and Custom Types
@PaulDaMacMan: There is some support in place for including the foreign library (for non system ones) inside the extension package... I'll check with Ali in the morning about how to make this work. The intention is that if you 'bind to' non system installed libraries in your module, then the necessary libraries should be present in the extension in a private folder.
Re: Foreign Handlers and Custom Types
Yeah, I've tried just about every variation I can think of to bind to libyaml. I've bound to system fine following @peter-b's blog post. It's probably something simple though so I'm just going to sit back and wait until @peter-b covers this stuff in his posts
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: Foreign Handlers and Custom Types
I'm not sure what you tried but according to apple
":The standard locations for header files are ~/include, /usr/local/include and /usr/include. The standard locations for dynamic libraries are ~/lib, /usr/local/lib, and /usr/lib"
If you are trying a non standard location you may have to run -oltool to edit the path.
There are some environment variables you can add to the dylib path such as @executable_path to help os x find the dylib.
I will let you guys google the details because I can't check anything myself.
":The standard locations for header files are ~/include, /usr/local/include and /usr/include. The standard locations for dynamic libraries are ~/lib, /usr/local/lib, and /usr/lib"
If you are trying a non standard location you may have to run -oltool to edit the path.
There are some environment variables you can add to the dylib path such as @executable_path to help os x find the dylib.
I will let you guys google the details because I can't check anything myself.
-
- Posts: 616
- Joined: Wed Apr 24, 2013 4:53 pm
- Contact:
Re: Foreign Handlers and Custom Types
Yeah that's what I was thinking on page 2 of this thread:
and also why I was looking up dlopen() to try (thinking it might be possible to force the lib to load), but I copied the lib to every directory I could think of that could be part of the search and still no dice.PaulDaMacMan wrote: I think the library needs to be built with option for relative paths (from gcc make) for those to work otherwise the lib needs to be in one of the default paths for libs (usr/lib/ , ~/lib , etc.) or you need to set an environmental variable first.
Re: Foreign Handlers and Custom Types
I'm all for just enough glue-code.LCMark wrote:I do wonder whether (for the time being at least), it might be worth adding some functions which allow you to dereference an offset from a pointer as all the native C storage types - that would enable you to build and decompose structs and C-style arrays right now.
Basically, with enough glue-code you should be able to wrap any API with those basic things.
Structures will be a pain and even a moving target, but simple structures and simple arrays should be OK.
I wonder what this just enough would look like. Does it exist already?