Martin Münstermann wrote:
> Hi!
>
> Martin M?nstermann wrote:
> >> OK, we now have thread compile failure reports on Debian and Slackware.
> >>
> >> The config/acx_pthread.m4 script basically tests these:
> >>
> >> acx_pthread_flags=3D"pthreads none -Kthread -kthread lthread -pthread
> >> -pthreads -mthreads pthread --thread-safe -mt pthread-config"
> >> =09
> >> in that order and exits once it finds the first one that can
> >> compile/link this:
> >>
> >> AC_TRY_LINK([#include <pthread.h>],
> >> [pthread_t th; pthread_join(th, 0);
> >> pthread_attr_init(0); pthread_cleanup_push(0, 0);
> >> pthread_create(0,0,0,0); pthread_cleanup_pop(0); ],
> >> [acx_pthread_ok=3Dyes])
> >>
> >> Now, the big question is why -pthread can compile/link this successfully
> >> but -pthread isn't enough to build a library that uses threads.
> >
> >
> > I suspect that on Solaris, without "-lpthread" the pthread-stubs in
> > /usr/lib/libc.so might be called at runtime instead of the functional
> > ones in libpthread.so.
> >
> > Could this easily be checked?
>
> I can confirm this suspect for Solaris8/gcc 3.2.3.
> How to reproduce it:
> Add a line like
> printf("### NOTE: check_sigpipe_handler called.\n");
> to check_sigpipe_handler() in fe-secure.c and rebuild libpq.so.
>
> The line is only dumped out (indicating that check_sigpipe_handler() is
> being called), when the library is linked with -lpthread.
> Without -lpthread no complains from the compiler or linker, but
> check_sigpipe_handler() is not called, because the stub of
> pthread_once() in libc.so does nothing.
>
> --> We need -lpthread on solaris, too.
So the current CVS code is good?
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
