The tar balls available on postgresql.org are not official. The only official PostgreSQL 
binaries for Solaris 10 are the ones bundled with Solaris 10 - versions 8.1, 8.2 & 8.3 
included in S10 updates 2 (6/06), 4 (8/07) & 6 (10/08). The 8.1 binaries are found in 
/usr, 8.2 & 8.3 binaries in /usr/postgres. But you can only get support for these with 
a PostgreSQL contract from Sun (which is no longer available since the Oracle acquisition).

The tar balls on postgresql.org are there for convenience (so you don't have to 
build it yourself). There's no support available for them.

But it does look like every library in 9.0-pgdg/lib is incorrectly linked with the 
old libpq.so.4 rather than 9.0 libpq.so.5. I've checked the rc1 & 9.0.1 tar 
balls, and all shared libraries in 9.0-pgdg/lib show this:

Dynamic Section:  .dynamic
    index  tag                value
      [0]  NEEDED            0x20b               libpq.so.4
      [1]  INIT              0x12b4
      [2]  FINI              0x12d0
      [3]  RUNPATH           0x216               
$ORIGIN/../lib:/usr/sfw/lib:/usr/postgres/9.0-pgdg/lib
      [4]  RPATH             0x216               
$ORIGIN/../lib:/usr/sfw/lib:/usr/postgres/9.0-pgdg/lib
...

Interestingly, everything in 9.0-pgdg/bin is correctly linked with libpq.so.5.

Anyway, I've bcc'd the person who maintains these tar balls. Hopefully he can 
resolve this problem & upload new tar balls.


Onno Molenkamp wrote:
James Gates schreef op 20-10-10 19:19:
You can probably override this by setting this in the environment in
which you run/start replication:

setenv LD_LIBRARAY_PATH=/disk0.7/postgres/postgres/9.0-pgdg/lib

Unlikely, as it's looking for libpq.so.4 but should be using libpq.so.5.
Had it been linked to the right version, there wouldn't have been a
problem, as $ORIGIN/../lib is the first entry in RPATH.

But the correct solution is to build libpqwalreceiver.so with the
correct linker settings i.e. Use RPATH or the -R flag during the build.

It's the 'official' 32 bit i386 Solaris 10 binaries on postgresql.org
that are broken this way, so can you (or someone else at Oracle) fix those?

(the 64 bit binaries seem to be ok)

Onno



------------------------------------------------------------------------

_______________________________________________
databases-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/databases-discuss

_______________________________________________
databases-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/databases-discuss

Reply via email to