On Tue, Apr 10, 2012 at 9:57 AM, Cameron Sanders <[email protected]> wrote:
> Mariano, > > *Thank you, regarding the 32 bits!* (I questioned that late one evening, > and then I forgot about that possibility!) > > When I said Seaside3.06, it was straight out of the box (download). *So I > will need to see which VM 3.06 has in it. How do I discover that?* I > stopped paying attention to the VMs etc, once the one-click installs came > with Cog. > In the MacOS directory of the one-click, the vm is "Squeak VM Opt". The date of the VM is September 10, 2011. > *It is not clear to me what client libraries I need from the DB vendor in > the case of Postgres. Is it included as part of the standard package? * -- > Any feedback here is greatly appreciated! > > Thanks for the information provided, and any more than you can offer! > Cam > > On Tue, Apr 10, 2012 at 4:01 AM, Mariano Martinez Peck < > [email protected]> wrote: > >> Hi. It would also help if you can tell use which VM are you using because >> the problem is in fact that FFI cannot find the opendbx library. >> Be aware that openDBX has to be compiled 32 bits. That is, if you are in >> a 64 bits machine, you will need to compile it for 32 bits. >> The same for the database client library. >> >> Cheers >> >> On Mon, Apr 9, 2012 at 6:02 PM, Guillermo Polito < >> [email protected]> wrote: >> >>> Hi!! >>> >>> >>> On Sun, Apr 8, 2012 at 11:53 PM, Cameron Sanders <[email protected]>wrote: >>> >>>> I am having difficulties getting set up and running with DBXTalk tools >>>> on a Mac. I hate to pester the community with some basics, but I am getting >>>> way too many hours in simply trying to connect to a Postgres DB. Any help >>>> or guidance that anyone can offer is greatly appreciated. >>>> >>>> Keep up the good work on Pharo! It is a great platform! [I have not >>>> checked in lately to see where things are with regard to us commercial >>>> operators contributing to the community, but I am overdue!] >>>> >>>> Thanks for the feedback in advance! >>>> -Cam >>>> >>>> >>>> *#1:* From http://dbxtalk.smallworks.com.ar/Download/ >>>> I see a paragraph near that top that reads: >>>> >>>> *If in the previous step you have installed OpenDBX by using its >>>> binaries (no compilation), then you must install the databse client library >>>> (C library) of your database.* >>>> >>>> By "client library", is the author referring to the libraries like >>>> libpgsqlbackend.* which is part of the opendbx binaries? Or do I need to >>>> install some posgres client from http://www.postgresql.org/? (My DB >>>> server is remote, and this computer knows nothing about it.) >>>> >>> Yes, you need to install another thing: the client libraries from the >>> database vendor. opendbx plays the role as an adaptor making the several >>> database platforms polymorphic (in some kind of way :) ). >>> See how to test it below in my reply. >>> >>>> I built the libs locally and successfully installed them -- after >>>> finding specs that the utils cannot be compiled for Mac. Permissions for >>>> all are read & execute, except for the ".a" libs which have only read >>>> permission. >>>> >>> >>> Hmm, how did you test it? >>> >>> You have to think of this (read the -> as "talks to"): >>> >>> (Smalltalk image with dbxtalk smalltalk library) -> opendbx c library -> >>> database vendor C library -----> database (remote or local, doesn't matter) >>> >>> so, first of all, what you have to test, is the opendbx c library with >>> the vendor's library (and therefore the database). You can do it executing >>> the following from the terminal: >>> >>> ./odbxtest -b pgsql -h localhost -p 5432 -d myDatabase -u myUser -w >>> myPass >>> >>> where: >>> >>> ./odbxtest -b <backend> -h <host> -p <port> -d <database name> -u <user> >>> -w <password> >>> >>> *#2: does Pharo know where to look for these libraries on a mac?* Or >>>> do I need to define environmental variables to point to them? After fishing >>>> around, I read about a file called environment.plist (xml key/value), where >>>> I defined the following environmental variables based on a link from >>>> dbxtalk pages to a 2008 blog, so now my environment.plist file is stored in >>>> ~/.MacOSX and contains the following: >>>> >>>> *<plist version="1.0"> >>>> **<dict> >>>> ** <key>LD_LIBRARY_PATH</key> >>>> ** <string>/usr/local/lib:usr/lib</string>* >>>> >>>> * <key>DYLD_LIBRARY_PATH**</key> >>>> ** <string>/usr/local/lib:usr/lib</string> >>>> **</dict></plist>* >>>> >>> *More questions:* A) do I need to include the /usr/local/lib/opendbx >>>> directory too, or do the dbx tools know to append that directory to the >>>> other path elements? and B) after logging back into my computer (actually I >>>> did a reboot -- it had been a while), I opened up a terminal, and executed >>>> printenv, but the aforementioned variables are not to be seen, is there a >>>> Mac expert in the crowd who knows why, or what the right way to do this is? >>>> >>> I'm not sure about this. I'm using linux, so let someone else answer >>> this point. >>> What about creating simlinks so you have >>> >>> /usr/lib/libopendbx.so --> /usr/lib/opendbx/libopendbx.so.whateverversion >>> >>> >>>> *#3:* *Does anybody offer up a fairly clean image that includes the >>>> standard seaside suite, and dbxtalk tools all pre-loaded?* >>>> >>>> I am just curious for the future, as I am currently stuck at testing >>>> the OpenDBXDriver connectivity. Which implies that I have more things to >>>> install and test. >>>> >>> >>> Nope, sorry :(. But providing a clean image with dbxtalk loaded is not >>> the problem. The problem is the rest of the environment you have to setup >>> in order to make it work. >>> >>> >>>> *#4 -- FFI question:* In seaside in the OpenDBXDriverTests the tests >>>> all fail. (Previously I had altered DBXPostgreFacility>>createConnection to >>>> match the db login specs.) When I debug the first failed test, it says >>>> "createConnection:" failed "Error: External module not found", which is >>>> what led to question(s) #2 up above. >>>> >>>> >>>> An additional question in my mind, is when I am debugging FFI >>>> connections, how can I find exactly what library it is trying to load >>>> during the failure? And what paths it tried? >>>> >>>> In this case, looking at the following, near the top of the stack in >>>> the debugger: >>>> OpenDBXMacOSX>>apiInitialize: handle backend: backend host: host port: >>>> port >>>> "long odbx_init(odbx_t**, char*, char*, char*)" >>>> <cdecl: long 'odbx_init' (ulong* char* char* char*) module: 'opendbx'> >>>> ^self externalCallFailed >>>> >>> >>> In unix, I think the LD_LIBRARY_PATH is followed. >>> >>> >>>> >>>> I see the reference to the module 'opendbx', so I presume that is the >>>> library being sought. *So is the general solution to finding "what" is >>>> being sought, to search for the pattern 'module:'?* >>>> >>> >>> which means libopendbx.so is the library that's looked for, at least in >>> unix. >>> >>> >>>> * >>>> * >>>> That still leaves the question of "*where*" it looked. Answers to #2 >>>> up above will likely address the rules, but the question stands: *is >>>> it possible in the debugger to see where it looked for the module? or is >>>> that simply too difficult.* >>>> >>> >>> I don't think current FFI implementation tells you that... >>> But there were some threads talking about specifying the module location >>> in the image code. So maybe in the future... :/ >>> >>> >>>> >>>> Note: FFI unit tests all pass except for one using Form -- "#makeStar >>>> method not found." >>>> >>>> Cheers, >>>> Cam >>>> >>>> >>>> >>> I hope to be of help. >>> BTW, subscribe to the dbxtalk mailing list, I think that list is the >>> idoneous place to ask this questions :). >>> >>> Don't hesitate to ask for more help if needed :). >>> Guille >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >
