Thread: pgsql on Solaris 10
Compiling PostgreSQL 8.1.4 under Solaris 10, I ran into a problem documented back on 2006-05-30. Apparently in order tocompile 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 forseveral hours tracking down the same problem? I have been a Free Software user for some time but am not familiar withways 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.) -----
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 tocompile 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 forseveral hours tracking down the same problem? I have been a Free Software user for some time but am not familiar withways 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
tocompile 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
forseveral hours tracking down the same problem? I have been a Free Software user for some time but am not familiar
withways 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