Forum OpenACS Q&A: Postgres.so load error with AOLS 2.3.3, Solaris 2.5.1

1: Postgres.so load error with AOLS 2.3.3, Solaris 2.5.1

Posted by Hugh Forrest on 07/04/00 02:38 PM

I built Postgres 7 (without C++ modules since the configure failed on
C++). Postgres runs up fine : postmaster, initdb, createdb and psql
work fine.

I loaded the AOLserver Postgres drive 1.0.1, made it with gmake.

I have a running AOLserver 2.3.3, all seems OK with this. (I note
that most here use AOLS 3 but this is a testbed for a live server
running v2.3.3; the postgres driver docs seem to state that it is OK
with 2.3.3)

When I configured the postgres.so into AOLserver, I now see the
following error in the server log :
[04/Jul/2000:13:17:50 +0100][587.4] Notice:
Loading module: /old669/aolserver2/bin/postgres.so
[04/Jul/2000:13:17:50 +0100][587.4] Warning:
Load of '/old669/aolserver2/bin/postgres.so' failed: ld.so.1:
/old669/aolserver2/bin/nsd: fatal: relocation error: file
/usr/local/pgsql/lib/libpq.so: symbol __umoddi3: referenced symbol
not found
[04/Jul/2000:13:17:50 +0100][587.4] Warning:
Db: Could not load driver: postgres.

There do not seem to exist any /etc/ld.so.conf or similar files so
ldconfig should not be needed should it?

I have checked execute rights in /usr/local/pgsql/lib.

I have read all postings here which seem to relate to a problem
anything like this and checked my installation accordingly.

I saw one note about loading the crypt library but have checked in
/usr/lib and subdirectories, no sign of it.

Grateful for any help,

2: Response to Postgres.so load error with AOLS 2.3.3, Solaris 2.5.1 (response to 1)

Posted by Dan Wickstrom on 07/04/00 03:02 PM

The driver has some dependencies on aolserver 3.0. I don't think anybody has really been supporting aolserver 2.3, so if you want it to work with aolserver 2.3, you'll probably have to hack the driver code yourself.

3: Response to Postgres.so load error with AOLS 2.3.3, Solaris 2.5.1 (response to 1)

Posted by Hugh Forrest on 07/04/00 03:34 PM

Thanks for the reply. I will have to try AOLserver v3 unless I can fix it quickly for v2.3.3.

It looks to me more like a PG or driver problem from the error message though, from the fact that it is looking for the routine in libpq.so - not any aol libs.

Annoying that the driver docs on a Web page (can't remember URL, sorry) state v2 is OK. Is this really not the case?

Cheers,

4: Response to Postgres.so load error with AOLS 2.3.3, Solaris 2.5.1 (response to 1)

Posted by Dan Wickstrom on 07/04/00 03:41 PM

I think it states that on the download page for the driver, but I think that is wrong. Looking at the driver code, I can see some dependencies for aolserver 3.0 with no equivalent support for 2.3. aolserver 2.3 is not opensource, so it's probably not supported.

5: Response to Postgres.so load error with AOLS 2.3.3, Solaris 2.5.1 (response to 1)

Posted by Lamar Owen on 07/04/00 04:09 PM

The current version of the postgres.so driver in the OpenACS CVS does indeed work on AOLserver 2.3.3 -- I'm using it in a production environment (on Linux).

The code is carefully constructed so that it conditionally includes things based on which version of AOLserver is in use, as well as if this is FOR_ACS_USE.

The error message referenced appears to be either caused by AOLserver's loader not being able to find libpq.so, or by libpq.so being improperly built.

Not being a Solaris expert, I wouldn't know where you'd need to put libpq.so to have the dynaloader find it -- try copying libpq.so to /usr/lib, rerun ldconfig (if Solaris needs that step), and try again.

Again, the load error is related to libpq.so, not postgres.so -- if postgres.so was improperly compiled, you'd get errors from it about undefined symbol, etc. The error that is being issued relates to postgres.so not being able to be linkloaded (relocated) due to libpq.so having a problem.

The libcrypt issue occurs on Linux, but I don't think it does on Solaris.

6: Response to Postgres.so load error with AOLS 2.3.3, Solaris 2.5.1 (response to 1)

Posted by Don Baccus on 07/04/00 04:53 PM

That library function looks supiciously like a solaris internal one, try "unsigned mod/divide" on for size and see how that fits as an interpretation.

What are you running Solaris on, a Sparc or x86?

Since psql works and depends on libpq, Postgres does seem to be properly installed. You might compare the link flags passed when linking it with the link flags passed when linking the postgres driver to make sure the system libraries are being referenced.

7: Response to Postgres.so load error with AOLS 2.3.3, Solaris 2.5.1 (response to 1)

Posted by Lamar Owen on 07/04/00 05:00 PM

RE: Psql depending upon libpq.so

It depends (pun intended) -- some architectures build psql with libpq.a statically linked, instead of linking against libpq.so dynamically. Running ldd against psql would tell the tale -- running ldd against postgres.so might also tell the tale. There may be another library that needs to be referenced, like libcrypt does on my Linux box.

8: Response to Postgres.so load error with AOLS 2.3.3, Solaris 2.5.1 (response to 1)

Posted by Dan Wickstrom on 07/04/00 05:45 PM

"The code is carefully constructed so that it conditionally includes things based on which version of AOLserver is in use, as well as if this is FOR_ACS_USE."

Lamar,

I think the 1.01 version linked from the openacs site doesn't include the changes that you made. It is based on postgres.c version 1.15 whereas the latest version in cvs is postgres.c version 1.20. The version 1.15 postgres.c file doesn't have the FOR_ACS_USE flag.

9: Response to Postgres.so load error with AOLS 2.3.3, Solaris 2.5.1 (response to 1)

Posted by Hugh Forrest on 07/04/00 07:59 PM

Thank you all very much for so much help so quickly.

I found the sourceforge files OK for the v1.20 driver so I will try this at work tomorrow.

Thanks again,

10: Response to Postgres.so load error with AOLS 2.3.3, Solaris 2.5.1 (response to 1)

Posted by Lamar Owen on 07/04/00 08:09 PM

RE: Postgres driver 1.15 versus 1.20

1.16 is where I rolled in some additional error handling from Jan Weick, and rolled in the FOR_ACS_USE conditional, so that a single driver could be merged into the AOLserver 3 distribution. AOL of course took out the 2.3.3 compatibility stuff for their end.

HOWEVER, _this_ driver has worked with 2.3.3 _since_ 1.1 days. In fact, 1.1 didn't work with 3.0.

The whole set of conditionals based on NS_AOLSERVER3_PLUS, mostly used in the negative ifndef state, handle the portions of the code necessary to support 2.3.3 versus 3.0 -- the extendedTableInfo stuff, BestRowId and friends, and the include of two more headers for the 2.x case.

And, I was wrong -- the code in use on my production 2.3.3 server (not running OpenACS) is more along the lines of driver version 1.11 or so, not the latest. I have built 1.16 for 2.3.3, and built 1.20 just last night for 2.3.3, to make sure it would build -- but that was on a different version of RedHat than what I am running on my production server.

The code is a little more complex now, as there are sections that need to be built or not built for four different build cases: AS 2.3, AS2.3+ACS, AS3, AS3+ACS. The plain AS 3 case has the least code, and the AS3+ACS has the most.