Foreign Handlers and Custom Types

[PaulDaMacMan]

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.

[LCMark]

@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.

[monte]

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

[n.allan]

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.

[PaulDaMacMan]

Yeah that's what I was thinking on page 2 of this thread:

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.

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.

[DarScott]

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.

I'm all for just enough glue-code.

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?