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