You are right that the "linker" normally resolves this. If you install  
the "opendbx-devel" package, it contains a symlink from libopendbx.so  
to libopendbx.so.1. When you normally link your program, the linker  
will examine the link and actually put a reference to libopendbx.so.1  
in the executable.

See "3.1.1. Shared Library Names" in
http://www.faqs.org/docs/Linux-HOWTO/Program-Library-HOWTO.html#AEN49

Now, when FFI needs to do the task of the linker, it needs the same  
libopendbx.so symlink, too, but it does not normally store the  
libopendbx.so.1 name. This is because in Squeak we usually do not  
distinguish between "compile/link time" and "run time". If we did  
this, the same image would not run on a different platform anymore.

However, you can of course manually do the "linking" step - in the ffi  
function declarations, use "libopendbx.so.1" as module instead of just  
"opendbx". This will then only work on Linux of course, since other  
Unix platforms use different schemes of versioning libraries.

- Bert -


On 30.04.2009, at 17:01, Mariano Martinez Peck wrote:

> Hi folks!
>
> I have a problem with SqueakDBX and FFI. I install openDBX from  
> a .deb and I get this:
>
> ldconfig -p | grep opendbx   show the same as you:
>
>     libopendbxplus.so.1 (libc6) => /usr/lib/libopendbxplus.so.1
>     libopendbx.so.1 (libc6) => /usr/lib/libopendbx.so.1
>
> The problem is that we (in squeakDBX) have as module: opendbx. Linux  
> looks for libMODULE_NAME.so.
>
> In this case, was searching libopendbx.so. But, my file was named  
> libopendbx.so.1. And of course, I got a 'unable to find function  
> address'.
>
> Solution: copy and rename (or just rename) libopendbx.so.1 to  
> libopendbx.so and worked like a charm.
>
> But, the question is, shouldn't FFI resolve this ? is this a matter  
> of the linker ?
>
> Thanks for the help!
>
> Mariano
>
>
>
> ---------- Forwarded message ----------
> From: Mariano Martinez Peck <marianopeck at gmail.com>
> Date: Tue, Apr 28, 2009 at 10:40 PM
> Subject: Re: [Pharo-project] squeakopendbx, which VM?
> To: Pharo-project at lists.gforge.inria.fr
>
>
> I think I fix it :)
>
> I took a clean Ubuntu. I did:
>
> sudo dpkg -i libopendbx1_1.4.0-1_i386.deb libopendbx1- 
> mysql_1.4.0-1_i386.deb
>
> Then  ldconfig -p | grep opendbx   show the same as you:
>
>
>     libopendbxplus.so.1 (libc6) => /usr/lib/libopendbxplus.so.1
>     libopendbx.so.1 (libc6) => /usr/lib/libopendbx.so.1
>
> The problem is that we have as module: opendbx. Ubuntu looks for  
> libMODULE_NAME.so.
>
> In this case, was searching libopendbx.so. But, your (and my) file  
> was named libopendbx.so.1.
>
> Solution: copy and rename (or just rename) libopendbx.so.1 to  
> libopendbx.so and should work like a charm.
>
> Thanks for your testing Hilaire. We want SqueakDBX to be as much  
> easier as possible. So, documenting the wiki with several cases will  
> definitively help us. I add this information to the wiki.
>
> Let me know if that work.
>
> Cheers,
>
> Mariano
>
>
>
>
> On Tue, Apr 28, 2009 at 2:56 PM, Mariano Martinez Peck <marianopeck at gmail.com 
> > wrote:
>
>
> 2009/4/28 Hilaire Fernandes <hilaire at ofset.org>
>
>
> 2009/4/28 Mariano Martinez Peck <marianopeck at gmail.com>
>
>
> I don't have it in my version of Pharo. I don't know if I can update  
> it without going through a full pharo image which I don't want to do  
> now.
>
>
> Ok. Doesn't matter. Your current problem is not about FFI but you  
> will have that problem then (when you get squeakDBX working). You  
> only need to get the latests FFI version from MC to work in pharo  
> with closure VM.
>
> I am pretty sure the VM I used is not with the fixed closure. I am  
> note sure about the image, I can tell you tomorrow the version  
> number of the image when at the office.
> Is the fixed closure mandatory to get SqueakDBX working?
> Which Pharo # image and VM should be used?
>
> SqueakDBX works with both. If you use a closure image you must use a  
> VM with closure an latest FFI (from MC). But, you can also use  
> Squeak in older version (non closure) with FFI from Universes. So,  
> no problem for you.
>
>
>
> I haven't my linux machine here, I will look tonight in my home, but:
>
> > 1) what do you have /usr/lib in PATH ?
> No it points only to binary as it should.
> Does FFI looks at PATH for the libraries? If so it is a buggy  
> behavior.
> I am really currious to know how FFI find the libraries...
>
> I am not sure about this. Perhaps someone (Andreas) can help us.
>
>
>
> 2) Just for testing, can you put the openDBX libraries in the same  
> directory where the pharo
> image is.
>
> 3) The same as 2) but where the VM is.
>
> I will try tomorrow morning.
>
> Which Linux are you using?  Perhaps there is a problem trying to  
> resolve the library. The last test you can do (just to see if it  
> works) is this:
>
> Go t class OpenDBXUnix and change the methods
>
> apiBind: handle database: databaseName name: userName password:  
> password method: method
>
> and
>
> apiInitialize: handle backend: backend host: host port: port
>
> In both, put module: 'libopendbx.so.1' or module: 'libopendbx.so'  
> instead of module: 'opendbx'
>
> I hope you get it working. Ask all what you want.
>
> Greetings,
>
> Mariano
>
>
>
> Thanks!
>
>
> Hilaire
>
>
> -- 
> http://blog.ofset.org/hilaire
>