Thanks Mariano. I will install the newer VM -- i just downloaded it. I will get the postgres binaries you refer to (libpg) -- thank you! And I will make certain opendbx is compiled with 32 bit; if 64 bit compilation was NOT the problem with it finding the libs, then I will then see if I can get the environmental variables to point to the right place.
(My first email was not clear: the libopendbx is installed in /usr/local/lib, but the backend specific components went into the subdir opendbx.) *Thank you so much for the help!* (Will you get to North America before you graduate?) -Cam On Tue, Apr 10, 2012 at 2:50 PM, Mariano Martinez Peck < [email protected]> wrote: > > > On Tue, Apr 10, 2012 at 3:57 PM, 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. >> >> *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! >> >> > I could rescue some information from the old squeakdbx website. What you > need is the C library. In PostgreSQL it is called libpq > > http://www.enterprisedb.com/products-services-training/pgdownload#osx > > that seems to include everything (like the server) and not only the libpq > (all you need). Not sure if the installer lets you only install the client > (libpq). > > But notice that your first problem is that FFI cannot find OpenDBX...which > is a step before than this one (OpenDBX trying to find the postgresql > client library) > > Cheers > > > >> 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 >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >
