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
