Use FFI to dynamically load shared library on Mac OS 10.5

I'm trying to dynamically load a shared library (.so) and consistently  
get "Unable to find function address." I have tried putting the  
library in a variety of locations (next to the executable, next to the  
image, next to the FFI package, etc.) and I have set the environment  
variable DYLD_LIBRARY_PATH to the location of the library. Nothing  
seems to work (although the FFI tests all pass). Any advice?

James Foster

The problem may not be that you aren't loading the library, it may be  
that you're not finding the address of the function within the  
library.  If you execute 'Smalltalk listLoadedModules' after a failed  
invocation attempt, does your shared library show up in the list?

Josh


On Jan 18, 2008, at 12:55 PM, James Foster wrote:

Josh,

Thanks for the idea. My image doesn't have #listLoadedModules. Since  
the code runs on other platforms (Linux/Windows), I think that the  
address could be found. Also, the handle is nil when I inspect the  
object. Interestingly, the #forceLoading method does not report any  
error--even if I give the wrong name!

GciLibrary new forceLoading handle. "@ 16r00000000"
FFITestLibrary new forceLoading handle. "@ 16r0028C830"

James


On Jan 18, 2008, at 1:01 PM, Joshua Gargus wrote:

Well if you are using the carbon library

http://www.smalltalkconsulting.com/html/squeakinfoplist.html

see

SqueakPluginsBuiltInOrLocalOnly

ah and oh look missing comment about  SqueakDebug

if you set SqueakDebug  to 1 versus 0, then the mac carbon VM will  
print all sorts of dianostics information as it tries to file the  
module, and entry point you've asked for.
This information likely will go to your console log


On Jan 18, 2008, at 12:55 PM, James Foster wrote:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

Josh,

SmalltalkImage current listLoadedModules. "My library is not in this  
list"

James

On Jan 18, 2008, at 1:01 PM, Joshua Gargus wrote:

Josh,

Thanks for the comments. 'SmalltalkImage current listLoadedModules'  
does not include my library. Since the code runs on other platforms  
(Linux/Windows), I think that the address could be found. Also, the  
handle is nil when I inspect the object. Interestingly, the  
#forceLoading method does not report any error--even if I give the  
wrong name!

GciLibrary new forceLoading handle. "@ 16r00000000"
FFITestLibrary new forceLoading handle. "@ 16r0028C830"

James


On Jan 18, 2008, at 1:01 PM, Joshua Gargus wrote:

The SqueakDebug flag was very helpful. I now have the message that it  
found the library but the library had the wrong architecture. Now that  
I think of it, this seems quite likely--I'm trying to load a 64-bit  
library into a 32-bit executable. I'll see if I can find a 32-bit  
library; I bet that will work. Thanks very much.

James

P.S. It would be nice if #forceLoading actually resulted in an error  
if the load fails.


On Jan 18, 2008, at 1:32 PM, John M McIntosh wrote:

On Jan 18, 2008, at 2:21 PM, James Foster wrote:

> The SqueakDebug flag was very helpful. I now have the message that  
> it found the library but the library had the wrong architecture. Now  
> that I think of it, this seems quite likely--I'm trying to load a 64-
> bit library into a 32-bit executable. I'll see if I can find a 32-
> bit library; I bet that will work. Thanks very much.
>
> James

Thanks, I added this feature because diagnosing *why* a FFI call  
didn't work was always most painful, find the library, nope, load the  
library, nope, find the function, nope, oh does the data being passed  
match the api: declare nope....   Lot's of nopes...

Today I noted that sending bad data to fileno() via FFI causes the VM  
to crash, that sounds like a buffer/overflow opportunity. Still the  
intent was
not to segfault, so yes saying longAt: 4   isn't really what you want,  
you want longAt: 5, something about that is that 0 based offseting  or  
1 based?

Just so I can say stat(fileno(squeak fileno),...)   to avoid the  
lengthy time to get modificationTime via reading the entire directory...

>
>
> P.S. It would be nice if #forceLoading actually resulted in an error  
> if the load fails.

The Squeak Mantis system awaits your request.


--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

On Jan 18, 2008, at 5:04 PM, John M McIntosh wrote:

I didn't know about the SqueakDebug .plist option before tonight,  
either.  Coincidentally, I just ended up needing it (and I hadn't even  
planned on doing any Mac VM hacking).

Thanks!
Josh

On Fri, Jan 18, 2008 at 02:21:53PM -0800, James Foster wrote:
> The SqueakDebug flag was very helpful. I now have the message that it  
> found the library but the library had the wrong architecture. Now that  
> I think of it, this seems quite likely--I'm trying to load a 64-bit  
> library into a 32-bit executable. I'll see if I can find a 32-bit  
> library; I bet that will work. Thanks very much.

FYI, the FFIPlugin will not currently work for 64 bit pointers (although
a 32 bit VM and plugin on 64 bit machine should be fine). I've been
working on sorting out the long pointer issues using an AMD Linux box.
Some significant changes are needed and I'll be out of town and busy
with other things for a couple of weeks, so it may be a while before
I report back on any progress.

Dave