FFI seaside3.06 Mac OSX Lion dbxtalk postgres - trouble shooting

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

FFI seaside3.06 Mac OSX Lion dbxtalk postgres - trouble shooting

Cameron Sanders
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


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

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.

#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?

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

#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

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:'?

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.

Note: FFI unit tests all pass except for one using Form -- "#makeStar method not found." 

Cheers,
Cam


Reply | Threaded
Open this post in threaded view
|

Re: FFI seaside3.06 Mac OSX Lion dbxtalk postgres - trouble shooting

Guillermo Polito
Hi!!


On Sun, Apr 8, 2012 at 11:53 PM, Cameron Sanders <[hidden email]> 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


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
Reply | Threaded
Open this post in threaded view
|

Re: FFI seaside3.06 Mac OSX Lion dbxtalk postgres - trouble shooting

Mariano Martinez Peck
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 <[hidden email]> wrote:
Hi!!


On Sun, Apr 8, 2012 at 11:53 PM, Cameron Sanders <[hidden email]> 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


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

Reply | Threaded
Open this post in threaded view
|

Re: FFI seaside3.06 Mac OSX Lion dbxtalk postgres - trouble shooting

Cameron Sanders
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 <[hidden email]> 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 <[hidden email]> wrote:
Hi!!


On Sun, Apr 8, 2012 at 11:53 PM, Cameron Sanders <[hidden email]> 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


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


Reply | Threaded
Open this post in threaded view
|

Re: FFI seaside3.06 Mac OSX Lion dbxtalk postgres - trouble shooting

Cameron Sanders

On Tue, Apr 10, 2012 at 9:57 AM, Cameron Sanders <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi!!


On Sun, Apr 8, 2012 at 11:53 PM, Cameron Sanders <[hidden email]> 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


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



Reply | Threaded
Open this post in threaded view
|

Re: FFI seaside3.06 Mac OSX Lion dbxtalk postgres - trouble shooting

Cameron Sanders
I no more than hit the send to my last (useless) note when I spotted the OneClick.txt which says:

This distribution is based on the following standard virtual machines:
- Mac OS X 4.2.5beta1U


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.


[rest of content dropped] 
Reply | Threaded
Open this post in threaded view
|

Re: FFI seaside3.06 Mac OSX Lion dbxtalk postgres - trouble shooting

Mariano Martinez Peck


On Tue, Apr 10, 2012 at 8:00 PM, Cameron Sanders <[hidden email]> wrote:
I no more than hit the send to my last (useless) note when I spotted the OneClick.txt which says:

This distribution is based on the following standard virtual machines:
- Mac OS X 4.2.5beta1U


Well...that's is terrible old :(
Can you try any of these:
- latest one from the jenkins: https://ci.lille.inria.fr/pharo/view/VM/job/Pharo-Mac-Cocoa/
- latest from Eliot's website: http://www.mirandabanda.org/files/Cog/VM/VM.r2540/Cog.app.tgz

Let us know.

 

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.


[rest of content dropped] 



--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: FFI seaside3.06 Mac OSX Lion dbxtalk postgres - trouble shooting

Mariano Martinez Peck
In reply to this post by Cameron Sanders


On Tue, Apr 10, 2012 at 3:57 PM, Cameron Sanders <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi!!


On Sun, Apr 8, 2012 at 11:53 PM, Cameron Sanders <[hidden email]> 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


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

Reply | Threaded
Open this post in threaded view
|

Re: FFI seaside3.06 Mac OSX Lion dbxtalk postgres - trouble shooting

Cameron Sanders
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 <[hidden email]> wrote:


On Tue, Apr 10, 2012 at 3:57 PM, Cameron Sanders <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi!!


On Sun, Apr 8, 2012 at 11:53 PM, Cameron Sanders <[hidden email]> 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


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