pgsql on Solaris 10

Based on the date of the posting, I think this will be fixed when we
release 8.1.5 soon. If you want, use CVS to pull the 8_1 tag and try
that.

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

vodhner@cox.net wrote:

Compiling PostgreSQL 8.1.4 under Solaris 10, I ran into a problem documented back on 2006-05-30. Apparently in order to compile successfully, one has to remove an unreferenced function pqsignalinquire() in src/interfaces/libpq/pqsignal.c.

Since I stepped into this hole, is there anything I can do to help ensure that nobody else has to get lost on Google for several hours tracking down the same problem? I have been a Free Software user for some time but am not familiar with ways of feeding back into the process.

Thanks,

Victor Odhner

-----

Details of the problem:

Removing the function eliminated the following error when linking "initdb":

Undefined symbol -- first referenced in file

sigmask -- ../../../src/interfaces/libpq/libpq.so

sigblock -- ../../../src/interfaces/libpq/libpq.so

ld: fatal: Symbol referencing errors. No output written to initdb

My guidance came from a posting by Tom Lane, 2006-05-30 --
http://archive.netbsd.se/?ml=pgsql-admin&a=2006-05&t=2058700 dated 2006-05-30

The rest of this message digests that posting.

Tom Lane Quoted Bruce Momjian from another discussion:
2004-01-08 21:02 momjian

* doc/src/sgml/libpq.sgml, src/backend/nodes/read.c,
src/interfaces/libpq/fe-connect.c, src/interfaces/libpq/fe-print.c,
src/interfaces/libpq/fe-secure.c, src/interfaces/libpq/libpq-fe.h,
src/interfaces/libpq/libpq-int.h, src/interfaces/libpq/pqsignal.c,
src/interfaces/libpq/pqsignal.h: Allow libpq to do thread-safe
SIGPIPE handling. This allows it to ignore SIGPIPE from send() in
libpq, but terminate on any other SIGPIPE, unless the user installs
their own signal handler.

This is a minor fix because the only time you get SIGPIPE from
libpq's send() is when the backend dies.

The code appears to unconditionally assume that sigmask() and sigblock() exist.
Not a good assumption.

(End of Momjian quote; Tom Lane continued . . .)

AFAICS pqsignalinquire() isn't even used anywhere (at least not in
HEAD), so the simplest answer may be to remove it rather than try to
fix it. It's in src/interfaces/libpq/pqsignal.c.

(V.Odhner comment: This worked for the person who started that discussion, and it seems to have worked for me.)

-----

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

vodhner@cox.net napsal(a):

Compiling PostgreSQL 8.1.4 under Solaris 10, I ran into a problem documented back on 2006-05-30. Apparently in order to compile successfully, one has to remove an unreferenced function pqsignalinquire() in src/interfaces/libpq/pqsignal.c.

Since I stepped into this hole, is there anything I can do to help ensure that nobody else has to get lost on Google for several hours tracking down the same problem? I have been a Free Software user for some time but am not familiar with ways of feeding back into the process.

Thanks,

Victor Odhner

-----

Details of the problem:

Removing the function eliminated the following error when linking "initdb":

Undefined symbol -- first referenced in file

sigmask -- ../../../src/interfaces/libpq/libpq.so

sigblock -- ../../../src/interfaces/libpq/libpq.so

ld: fatal: Symbol referencing errors. No output written to initdb

The postgresql 8.1.4 is standard part of solaris 10 update 2. You can
download prepared packages from pgfoundry. However, if you want to
compile by yourself, check if you have correct setup of LD_LIBRARY_PATH
to the related libc. I have never had problem with postgres compilation
on solaris 10 and opensolaris (nevada).

Zdenek