Thread: 7.4.2 on Solaris 9 - Error

Hi.

I want to install postgres 7.4.2 on solaris 9.

I configure with:  ./configure --enable-thread-safety
and it works fine (no error).

When I do "gmake", I get this error:

thread.c: In function `pqGetpwuid':
thread.c:116: error: too many arguments to function `getpwuid_r'
make[3]: *** [thread.o] Error 1
make[3]: Leaving directory
`/home/postgres/postgresql-7.4.2/src/interfaces/libpq'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/postgres/postgresql-7.4.2/src/interfaces'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/postgres/postgresql-7.4.2/src'
make: *** [all] Error 2

Anybody knows the problem?

Thanks.

CG

On Fri, 19 Mar 2004, Carmen Gloria Sepulveda Dedes wrote:

> Hi.
>
> I want to install postgres 7.4.2 on solaris 9.
>
> I configure with:  ./configure --enable-thread-safety
> and it works fine (no error).
>
> When I do "gmake", I get this error:
>
> thread.c: In function `pqGetpwuid':
> thread.c:116: error: too many arguments to function `getpwuid_r'
> make[3]: *** [thread.o] Error 1
> make[3]: Leaving directory
> `/home/postgres/postgresql-7.4.2/src/interfaces/libpq'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/home/postgres/postgresql-7.4.2/src/interfaces'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/postgres/postgresql-7.4.2/src'
> make: *** [all] Error 2
>
> Anybody knows the problem?
>

This problem was just recently fixed in cvs and will go out in the 7.4.3
release.  For no your best bet is to checkout the 7.4 branch from cvs, or
search the pgsql-committers archives to find the patch you need to apply.

Kris Jurka

Kris Jurka wrote:
> This problem was just recently fixed in cvs and will go out in the 7.4.3
> release.  For no your best bet is to checkout the 7.4 branch from cvs, or
> search the pgsql-committers archives to find the patch you need to apply.

I just recently went through installing 7.4.2 on Solaris. The attached
two patches did the trick for me (and both should match the tip of the
7.4 stable branch).

HTH,

Joe

*** src/port/thread.c.orig    Mon Mar 22 18:24:17 2004
--- src/port/thread.c    Mon Mar 22 18:24:45 2004
***************
*** 116,122 ****
       * Early POSIX draft of getpwuid_r() returns 'struct passwd *'.
       *    getpwuid_r(uid, resultbuf, buffer, buflen)
       */
!     result = getpwuid_r(uid, resultbuf, buffer, buflen);
  #endif
  #else

--- 116,122 ----
       * Early POSIX draft of getpwuid_r() returns 'struct passwd *'.
       *    getpwuid_r(uid, resultbuf, buffer, buflen)
       */
!     *result = getpwuid_r(uid, resultbuf, buffer, buflen);
  #endif
  #else

Index: configure
===================================================================
RCS file: /cvsroot/pgsql-server/configure,v
retrieving revision 1.310.2.8
diff -c -c -r1.310.2.8 configure
*** configure    5 Mar 2004 19:57:18 -0000    1.310.2.8
--- configure    20 Mar 2004 15:36:01 -0000
***************
*** 13484,13489 ****
--- 13484,13548 ----

  CFLAGS="$_CFLAGS"
  LIBS="$_LIBS"
+ echo "$as_me:$LINENO: checking whether getpwuid_r takes a fifth argument" >&5
+ echo $ECHO_N "checking whether getpwuid_r takes a fifth argument... $ECHO_C" >&6
+ if test "${pgac_func_getpwuid_r_5arg+set}" = set; then
+   echo $ECHO_N "(cached) $ECHO_C" >&6
+ else
+   cat >conftest.$ac_ext <<_ACEOF
+ #line $LINENO "configure"
+ #include "confdefs.h"
+ #include <sys/types.h>
+ #include <pwd.h>
+ #ifdef F77_DUMMY_MAIN
+ #  ifdef __cplusplus
+      extern "C"
+ #  endif
+    int F77_DUMMY_MAIN() { return 1; }
+ #endif
+ int
+ main ()
+ {
+ uid_t uid;
+ struct passwd *space;
+ char *buf;
+ size_t bufsize;
+ struct passwd **result;
+ getpwuid_r(uid, space, buf, bufsize, result);
+   ;
+   return 0;
+ }
+ _ACEOF
+ rm -f conftest.$ac_objext
+ if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+   (eval $ac_compile) 2>&5
+   ac_status=$?
+   echo "$as_me:$LINENO: \$? = $ac_status" >&5
+   (exit $ac_status); } &&
+          { ac_try='test -s conftest.$ac_objext'
+   { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+   (eval $ac_try) 2>&5
+   ac_status=$?
+   echo "$as_me:$LINENO: \$? = $ac_status" >&5
+   (exit $ac_status); }; }; then
+   pgac_func_getpwuid_r_5arg=yes
+ else
+   echo "$as_me: failed program was:" >&5
+ cat conftest.$ac_ext >&5
+ pgac_func_getpwuid_r_5arg=no
+ fi
+ rm -f conftest.$ac_objext conftest.$ac_ext
+ fi
+ echo "$as_me:$LINENO: result: $pgac_func_getpwuid_r_5arg" >&5
+ echo "${ECHO_T}$pgac_func_getpwuid_r_5arg" >&6
+ if test x"$pgac_func_getpwuid_r_5arg" = xyes ; then
+
+ cat >>confdefs.h <<\_ACEOF
+ #define GETPWUID_R_5ARG
+ _ACEOF
+
+ fi
+
  fi


Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql-server/configure.in,v
retrieving revision 1.301.2.6
diff -c -c -r1.301.2.6 configure.in
*** configure.in    5 Mar 2004 19:57:20 -0000    1.301.2.6
--- configure.in    20 Mar 2004 15:36:02 -0000
***************
*** 1061,1066 ****
--- 1061,1067 ----
  AC_CHECK_FUNCS([strerror_r getpwuid_r gethostbyname_r])
  CFLAGS="$_CFLAGS"
  LIBS="$_LIBS"
+ PGAC_FUNC_GETPWUID_R_5ARG
  fi


Index: config/c-library.m4
===================================================================
RCS file: /cvsroot/pgsql-server/config/c-library.m4,v
retrieving revision 1.23
diff -c -c -r1.23 c-library.m4
*** config/c-library.m4    23 Jul 2003 23:30:39 -0000    1.23
--- config/c-library.m4    20 Mar 2004 15:36:03 -0000
***************
*** 73,78 ****
--- 73,101 ----
  ])# PGAC_FUNC_GETTIMEOFDAY_1ARG


+ # PGAC_FUNC_GETPWUID_R_5ARG
+ # ---------------------------
+ # Check if getpwuid_r() takes a fifth argument (later POSIX standard, not draft version)
+ # If so, define GETPWUID_R_5ARG
+ AC_DEFUN([PGAC_FUNC_GETPWUID_R_5ARG],
+ [AC_CACHE_CHECK(whether getpwuid_r takes a fifth argument,
+ pgac_func_getpwuid_r_5arg,
+ [AC_TRY_COMPILE([#include <sys/types.h>
+ #include <pwd.h>],
+ [uid_t uid;
+ struct passwd *space;
+ char *buf;
+ size_t bufsize;
+ struct passwd **result;
+ getpwuid_r(uid, space, buf, bufsize, result);],
+ [pgac_func_getpwuid_r_5arg=yes],
+ [pgac_func_getpwuid_r_5arg=no])])
+ if test x"$pgac_func_getpwuid_r_5arg" = xyes ; then
+   AC_DEFINE(GETPWUID_R_5ARG,, [Define to 1 if getpwuid_r() takes a 5th argument.])
+ fi
+ ])# PGAC_FUNC_GETPWUID_R_5ARG
+
+
  # PGAC_UNION_SEMUN
  # ----------------
  # Check if `union semun' exists. Define HAVE_UNION_SEMUN if so.
Index: src/include/pg_config.h.in
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/pg_config.h.in,v
retrieving revision 1.64.2.2
diff -c -c -r1.64.2.2 pg_config.h.in
*** src/include/pg_config.h.in    11 Feb 2004 17:32:09 -0000    1.64.2.2
--- src/include/pg_config.h.in    20 Mar 2004 15:36:04 -0000
***************
*** 43,48 ****
--- 43,51 ----
     (--enable-thread-safety) */
  #undef ENABLE_THREAD_SAFETY

+ /* Define to 1 if getpwuid_r() takes a 5th argument. */
+ #undef GETPWUID_R_5ARG
+
  /* Define to 1 if gettimeofday() takes only 1 argument. */
  #undef GETTIMEOFDAY_1ARG

Index: src/port/thread.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/port/thread.c,v
retrieving revision 1.12.2.3
diff -c -c -r1.12.2.3 thread.c
*** src/port/thread.c    14 Mar 2004 14:01:54 -0000    1.12.2.3
--- src/port/thread.c    20 Mar 2004 15:36:05 -0000
***************
*** 107,120 ****
             size_t buflen, struct passwd **result)
  {
  #if defined(FRONTEND) && defined(ENABLE_THREAD_SAFETY) && defined(NEED_REENTRANT_FUNCS) && defined(HAVE_GETPWUID_R)
      /*
       * Early POSIX draft of getpwuid_r() returns 'struct passwd *'.
       *    getpwuid_r(uid, resultbuf, buffer, buflen)
-      * Do we need to support it?  bjm 2003-08-14
       */
!     /* POSIX version */
!     getpwuid_r(uid, resultbuf, buffer, buflen, result);
!
  #else

  #if defined(FRONTEND) && defined(ENABLE_THREAD_SAFETY) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_GETPWUID_R)
--- 107,123 ----
             size_t buflen, struct passwd **result)
  {
  #if defined(FRONTEND) && defined(ENABLE_THREAD_SAFETY) && defined(NEED_REENTRANT_FUNCS) && defined(HAVE_GETPWUID_R)
+
+ #ifdef GETPWUID_R_5ARG
+     /* POSIX version */
+     getpwuid_r(uid, resultbuf, buffer, buflen, result);
+ #else
      /*
       * Early POSIX draft of getpwuid_r() returns 'struct passwd *'.
       *    getpwuid_r(uid, resultbuf, buffer, buflen)
       */
!     result = getpwuid_r(uid, resultbuf, buffer, buflen);
! #endif
  #else

  #if defined(FRONTEND) && defined(ENABLE_THREAD_SAFETY) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_GETPWUID_R)

Kris Jurka wrote:

>
> On Fri, 19 Mar 2004, Carmen Gloria Sepulveda Dedes wrote:
>
>> Hi.
>>
>> I want to install postgres 7.4.2 on solaris 9.
>>
>> I configure with:  ./configure --enable-thread-safety
>> and it works fine (no error).
>>
>> When I do "gmake", I get this error:
>>
>> thread.c: In function `pqGetpwuid':
>> thread.c:116: error: too many arguments to function `getpwuid_r'
>> make[3]: *** [thread.o] Error 1
>> make[3]: Leaving directory
>> `/home/postgres/postgresql-7.4.2/src/interfaces/libpq'
>> make[2]: *** [all] Error 2
>> make[2]: Leaving directory `/home/postgres/postgresql-7.4.2/src/interfaces'
>> make[1]: *** [all] Error 2
>> make[1]: Leaving directory `/home/postgres/postgresql-7.4.2/src'
>> make: *** [all] Error 2
>>
>> Anybody knows the problem?
>>
>
> This problem was just recently fixed in cvs and will go out in the 7.4.3
> release.  For no your best bet is to checkout the 7.4 branch from cvs, or
> search the pgsql-committers archives to find the patch you need to apply.

Isn't that funny ... I just yesterday ran into the same problem with
7.4.2 on Solaris.

One other problem I am looking into (and why I tried to compile with
thread safety in the first place) is that this somehow did not turn on
-D_REENTRANT in the CFLAGS for libpq. And that leads to libpq not using
the threadsafe definition of errno, leading to serious communication
trouble in the end (pqReadData() failing with ENOENT while the real
error is a harmless EAGAIN from a nonblocking recv()).


Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

On 3/25/04 7:27 AM, "Jan Wieck" <JanWieck@yahoo.com> wrote:

> One other problem I am looking into (and why I tried to compile with
> thread safety in the first place) is that this somehow did not turn on
> -D_REENTRANT in the CFLAGS for libpq. And that leads to libpq not using
> the threadsafe definition of errno, leading to serious communication
> trouble in the end (pqReadData() failing with ENOENT while the real
> error is a harmless EAGAIN from a nonblocking recv()).

This sounds like the problem I just solved late yesterday, except that I'm
seeing it manifest itself in ecpglib with C programs build using ecpg. I had
absolutely no error handling.  The error flag was never set.  I put some
debug code into the various library functions and found it was setting the
error code in sqlca - but in a different copy of sqlca than was active.

The root problem turns out to be that configure is setting -pthread instead
of -lpthread in config.status.  I manually changed the config.status line

   s,@THREAD_LIBS@,-pthread,;t t

To

   s,@THREAD_LIBS@,-lpthread,;t t

And everything appears to be working now.  I don't see -D_REENTRANT being
set, but everything appears to work now.

Let me know if this solves your test case also.

Wes

Changing config.status, now that's what I call a quick and dirty hack.

The attached diff against 7.4.2 incorporates Joe Conway's checks for
getqwuid_r() has 4/5 arguments with a pthread compile autoconf check
that I found a while back in the gnu autoconf archives.

I think we should change alltogether to that pthread check.


Jan

wespvp@syntegra.com wrote:

> On 3/25/04 7:27 AM, "Jan Wieck" <JanWieck@yahoo.com> wrote:
>
>> One other problem I am looking into (and why I tried to compile with
>> thread safety in the first place) is that this somehow did not turn on
>> -D_REENTRANT in the CFLAGS for libpq. And that leads to libpq not using
>> the threadsafe definition of errno, leading to serious communication
>> trouble in the end (pqReadData() failing with ENOENT while the real
>> error is a harmless EAGAIN from a nonblocking recv()).
>
> This sounds like the problem I just solved late yesterday, except that I'm
> seeing it manifest itself in ecpglib with C programs build using ecpg. I had
> absolutely no error handling.  The error flag was never set.  I put some
> debug code into the various library functions and found it was setting the
> error code in sqlca - but in a different copy of sqlca than was active.
>
> The root problem turns out to be that configure is setting -pthread instead
> of -lpthread in config.status.  I manually changed the config.status line
>
>    s,@THREAD_LIBS@,-pthread,;t t
>
> To
>
>    s,@THREAD_LIBS@,-lpthread,;t t
>
> And everything appears to be working now.  I don't see -D_REENTRANT being
> set, but everything appears to work now.
>
> Let me know if this solves your test case also.
>
> Wes
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org


--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

wespvp@syntegra.com wrote:
> On 3/25/04 3:43 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
>
> > I assume you were using 7.4.0, rather than 7.4.2.  Current CVS has in
> > template/solaris:
> >
> >
> > # tools/thread/thread_test must be run
> > # -D_POSIX_PTHREAD_SEMANTICS enables 5-arg getpwuid_r, among other
> > things
> > if test "$GCC" = yes
> > then    THREAD_CPPFLAGS="-D_POSIX_PTHREAD_SEMANTICS"
> >        THREAD_LIBS="-pthread"
> > else    THREAD_CPPFLAGS="-mt -D_POSIX_PTHREAD_SEMANTICS"
> >        THREAD_LIBS="-lpthread"
> > fi
>
> I'm right in the middle - using 7.4.1 with GCC.  However, I did try 7.4.2
> and it has the same problem.
>
> Looks like a typo in template/solaris, and certainly explains the bad
> parameter on gcc.  The "if gcc" has the incorrect "-pthread".
>
> This would seem an appropriate place to add - -D_REENTRANT to fix the errno
> issue, wouldn't it?

Are you sure your change is correct?  We just added
"-D_POSIX_PTHREAD_SEMANTICS" in post 7.4.2, and the submitters did not
mention any problems with the -pthread line for gcc.

I just tried it on Sourceforge's Solaris 9 and I see:

    bash-2.05$ gcc -pthread
    gcc: unrecognized option `-pthread'
    gcc: no input files

which seems to indicate you are right.  I am kind of surprised.  Some
platforms to take -pthread, some -lpthread, so I am pretty sure it was
specified by the original Solaris guy.

OK, new template/solaris version applied to 7.4.X and head:

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


if test "$GCC" != yes ; then
  CC="$CC -Xa"            # relaxed ISO C mode
  CFLAGS="-O -v"        # -v is like gcc -Wall
fi

# Pick right test-and-set (TAS) code.
case $host in
  sparc-*-solaris*)  need_tas=yes; tas_file=solaris_sparc.s ;;
  i?86-*-solaris*)   need_tas=yes; tas_file=solaris_i386.s ;;
esac

THREAD_SUPPORT=yes
NEED_REENTRANT_FUNCS=yes    # 5.6 2003-09-13
THREAD_CPPFLAGS="-D_POSIX_PTHREAD_SEMANTICS"
if test "$GCC" != yes
then    THREAD_CPPFLAGS="$THREAD_CPPFLAGS -mt"
fi
THREAD_LIBS="-lpthread"

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On 3/25/04 3:43 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:

> I assume you were using 7.4.0, rather than 7.4.2.  Current CVS has in
> template/solaris:
>
>
> # tools/thread/thread_test must be run
> # -D_POSIX_PTHREAD_SEMANTICS enables 5-arg getpwuid_r, among other
> things
> if test "$GCC" = yes
> then    THREAD_CPPFLAGS="-D_POSIX_PTHREAD_SEMANTICS"
>        THREAD_LIBS="-pthread"
> else    THREAD_CPPFLAGS="-mt -D_POSIX_PTHREAD_SEMANTICS"
>        THREAD_LIBS="-lpthread"
> fi

I'm right in the middle - using 7.4.1 with GCC.  However, I did try 7.4.2
and it has the same problem.

Looks like a typo in template/solaris, and certainly explains the bad
parameter on gcc.  The "if gcc" has the incorrect "-pthread".

This would seem an appropriate place to add - -D_REENTRANT to fix the errno
issue, wouldn't it?

Wes

Jan Wieck wrote:
> Changing config.status, now that's what I call a quick and dirty hack.
>
> The attached diff against 7.4.2 incorporates Joe Conway's checks for
> getqwuid_r() has 4/5 arguments with a pthread compile autoconf check
> that I found a while back in the gnu autoconf archives.
>
> I think we should change alltogether to that pthread check.
>

Intersting.  Would this change require us to update to a newer version
of autoconf?

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

>
> Jan
>
> wespvp@syntegra.com wrote:
>
> > On 3/25/04 7:27 AM, "Jan Wieck" <JanWieck@yahoo.com> wrote:
> >
> >> One other problem I am looking into (and why I tried to compile with
> >> thread safety in the first place) is that this somehow did not turn on
> >> -D_REENTRANT in the CFLAGS for libpq. And that leads to libpq not using
> >> the threadsafe definition of errno, leading to serious communication
> >> trouble in the end (pqReadData() failing with ENOENT while the real
> >> error is a harmless EAGAIN from a nonblocking recv()).
> >
> > This sounds like the problem I just solved late yesterday, except that I'm
> > seeing it manifest itself in ecpglib with C programs build using ecpg. I had
> > absolutely no error handling.  The error flag was never set.  I put some
> > debug code into the various library functions and found it was setting the
> > error code in sqlca - but in a different copy of sqlca than was active.
> >
> > The root problem turns out to be that configure is setting -pthread instead
> > of -lpthread in config.status.  I manually changed the config.status line
> >
> >    s,@THREAD_LIBS@,-pthread,;t t
> >
> > To
> >
> >    s,@THREAD_LIBS@,-lpthread,;t t
> >
> > And everything appears to be working now.  I don't see -D_REENTRANT being
> > set, but everything appears to work now.
> >
> > Let me know if this solves your test case also.
> >
> > Wes
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
>
> --
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me.                                  #
> #================================================== JanWieck@Yahoo.com #

[ application/x-gzip is not supported, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

wespvp@syntegra.com wrote:
> On 3/25/04 7:27 AM, "Jan Wieck" <JanWieck@yahoo.com> wrote:
>
> > One other problem I am looking into (and why I tried to compile with
> > thread safety in the first place) is that this somehow did not turn on
> > -D_REENTRANT in the CFLAGS for libpq. And that leads to libpq not using
> > the threadsafe definition of errno, leading to serious communication
> > trouble in the end (pqReadData() failing with ENOENT while the real
> > error is a harmless EAGAIN from a nonblocking recv()).
>
> This sounds like the problem I just solved late yesterday, except that I'm
> seeing it manifest itself in ecpglib with C programs build using ecpg. I had
> absolutely no error handling.  The error flag was never set.  I put some
> debug code into the various library functions and found it was setting the
> error code in sqlca - but in a different copy of sqlca than was active.
>
> The root problem turns out to be that configure is setting -pthread instead
> of -lpthread in config.status.  I manually changed the config.status line
>
>    s,@THREAD_LIBS@,-pthread,;t t
>
> To
>
>    s,@THREAD_LIBS@,-lpthread,;t t
>
> And everything appears to be working now.  I don't see -D_REENTRANT being
> set, but everything appears to work now.
>
> Let me know if this solves your test case also.

I assume you were using 7.4.0, rather than 7.4.2.  Current CVS has in
template/solaris:


    # tools/thread/thread_test must be run
    # -D_POSIX_PTHREAD_SEMANTICS enables 5-arg getpwuid_r, among other
    things
    if test "$GCC" = yes
    then    THREAD_CPPFLAGS="-D_POSIX_PTHREAD_SEMANTICS"
            THREAD_LIBS="-pthread"
    else    THREAD_CPPFLAGS="-mt -D_POSIX_PTHREAD_SEMANTICS"
            THREAD_LIBS="-lpthread"
    fi

That should work for you.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Jan Wieck wrote:
> > This problem was just recently fixed in cvs and will go out in the 7.4.3
> > release.  For no your best bet is to checkout the 7.4 branch from cvs, or
> > search the pgsql-committers archives to find the patch you need to apply.
>
> Isn't that funny ... I just yesterday ran into the same problem with
> 7.4.2 on Solaris.
>
> One other problem I am looking into (and why I tried to compile with
> thread safety in the first place) is that this somehow did not turn on
> -D_REENTRANT in the CFLAGS for libpq. And that leads to libpq not using
> the threadsafe definition of errno, leading to serious communication
> trouble in the end (pqReadData() failing with ENOENT while the real
> error is a harmless EAGAIN from a nonblocking recv()).

Please try REL7_4_STABLE to see if that works.  It has several Solaris
thread fixes, both for getpwuid_r and template/solaris.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:
> Jan Wieck wrote:
>> Changing config.status, now that's what I call a quick and dirty hack.
>>
>> The attached diff against 7.4.2 incorporates Joe Conway's checks for
>> getqwuid_r() has 4/5 arguments with a pthread compile autoconf check
>> that I found a while back in the gnu autoconf archives.
>>
>> I think we should change alltogether to that pthread check.
>>
>
> Intersting.  Would this change require us to update to a newer version
> of autoconf?

works here with 2.53 and 2.57.


Jan

>
> ---------------------------------------------------------------------------
>
>>
>> Jan
>>
>> wespvp@syntegra.com wrote:
>>
>> > On 3/25/04 7:27 AM, "Jan Wieck" <JanWieck@yahoo.com> wrote:
>> >
>> >> One other problem I am looking into (and why I tried to compile with
>> >> thread safety in the first place) is that this somehow did not turn on
>> >> -D_REENTRANT in the CFLAGS for libpq. And that leads to libpq not using
>> >> the threadsafe definition of errno, leading to serious communication
>> >> trouble in the end (pqReadData() failing with ENOENT while the real
>> >> error is a harmless EAGAIN from a nonblocking recv()).
>> >
>> > This sounds like the problem I just solved late yesterday, except that I'm
>> > seeing it manifest itself in ecpglib with C programs build using ecpg. I had
>> > absolutely no error handling.  The error flag was never set.  I put some
>> > debug code into the various library functions and found it was setting the
>> > error code in sqlca - but in a different copy of sqlca than was active.
>> >
>> > The root problem turns out to be that configure is setting -pthread instead
>> > of -lpthread in config.status.  I manually changed the config.status line
>> >
>> >    s,@THREAD_LIBS@,-pthread,;t t
>> >
>> > To
>> >
>> >    s,@THREAD_LIBS@,-lpthread,;t t
>> >
>> > And everything appears to be working now.  I don't see -D_REENTRANT being
>> > set, but everything appears to work now.
>> >
>> > Let me know if this solves your test case also.
>> >
>> > Wes
>> >
>> >
>> > ---------------------------(end of broadcast)---------------------------
>> > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>>
>>
>> --
>> #======================================================================#
>> # It's easier to get forgiveness for being wrong than for being right. #
>> # Let's break this rule - forgive me.                                  #
>> #================================================== JanWieck@Yahoo.com #
>
> [ application/x-gzip is not supported, skipping... ]
>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 7: don't forget to increase your free space map settings
>


--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

On 3/25/04 4:13 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:

> Are you sure your change is correct?  We just added
> "-D_POSIX_PTHREAD_SEMANTICS" in post 7.4.2, and the submitters did not
> mention any problems with the -pthread line for gcc.
>
> I just tried it on Sourceforge's Solaris 9 and I see:
>
> bash-2.05$ gcc -pthread
> gcc: unrecognized option `-pthread'
> gcc: no input files
>
> which seems to indicate you are right.  I am kind of surprised.  Some
> platforms to take -pthread, some -lpthread, so I am pretty sure it was
> specified by the original Solaris guy.

Don't know...  I assume it was just a typo that wouldn't show up if you were
using SUNWSPRO compiler instead of GCC.

> OK, new template/solaris version applied to 7.4.X and head:

[snip]

> THREAD_SUPPORT=yes
> NEED_REENTRANT_FUNCS=yes    # 5.6 2003-09-13
> THREAD_CPPFLAGS="-D_POSIX_PTHREAD_SEMANTICS"
> if test "$GCC" != yes
> then    THREAD_CPPFLAGS="$THREAD_CPPFLAGS -mt"
> fi
> THREAD_LIBS="-lpthread"

Shouldn't that be

THREAD_CPPFLAGS="-D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS"

According to Jan, -D_REENTRANT must also be specified for libpq to be built
correctly.

Why isn't -D_THREAD_SAFE required also?

Wes

wespvp@syntegra.com wrote:
> On 3/25/04 4:13 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
>
> > Are you sure your change is correct?  We just added
> > "-D_POSIX_PTHREAD_SEMANTICS" in post 7.4.2, and the submitters did not
> > mention any problems with the -pthread line for gcc.
> >
> > I just tried it on Sourceforge's Solaris 9 and I see:
> >
> > bash-2.05$ gcc -pthread
> > gcc: unrecognized option `-pthread'
> > gcc: no input files
> >
> > which seems to indicate you are right.  I am kind of surprised.  Some
> > platforms to take -pthread, some -lpthread, so I am pretty sure it was
> > specified by the original Solaris guy.
>
> Don't know...  I assume it was just a typo that wouldn't show up if you were
> using SUNWSPRO compiler instead of GCC.
>
> > OK, new template/solaris version applied to 7.4.X and head:
>
> [snip]
>
> > THREAD_SUPPORT=yes
> > NEED_REENTRANT_FUNCS=yes    # 5.6 2003-09-13
> > THREAD_CPPFLAGS="-D_POSIX_PTHREAD_SEMANTICS"
> > if test "$GCC" != yes
> > then    THREAD_CPPFLAGS="$THREAD_CPPFLAGS -mt"
> > fi
> > THREAD_LIBS="-lpthread"
>
> Shouldn't that be
>
> THREAD_CPPFLAGS="-D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS"
>
> According to Jan, -D_REENTRANT must also be specified for libpq to be built
> correctly.

OK, I added -D_REENTRANT.

> Why isn't -D_THREAD_SAFE required also?

No idea?  Someone?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

> wespvp@syntegra.com wrote:
>> On 3/25/04 3:43 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
>>
>> > I assume you were using 7.4.0, rather than 7.4.2.  Current CVS has in
>> > template/solaris:
>> >
>> >
>> > # tools/thread/thread_test must be run
>> > # -D_POSIX_PTHREAD_SEMANTICS enables 5-arg getpwuid_r, among other
>> > things
>> > if test "$GCC" = yes
>> > then    THREAD_CPPFLAGS="-D_POSIX_PTHREAD_SEMANTICS"
>> >        THREAD_LIBS="-pthread"
>> > else    THREAD_CPPFLAGS="-mt -D_POSIX_PTHREAD_SEMANTICS"
>> >        THREAD_LIBS="-lpthread"
>> > fi
>>
>> I'm right in the middle - using 7.4.1 with GCC.  However, I did try 7.4.2
>> and it has the same problem.
>>
>> Looks like a typo in template/solaris, and certainly explains the bad
>> parameter on gcc.  The "if gcc" has the incorrect "-pthread".
>>
>> This would seem an appropriate place to add - -D_REENTRANT to fix the errno
>> issue, wouldn't it?
>
> Are you sure your change is correct?  We just added
> "-D_POSIX_PTHREAD_SEMANTICS" in post 7.4.2, and the submitters did not
> mention any problems with the -pthread line for gcc.
>
> I just tried it on Sourceforge's Solaris 9 and I see:
>
>     bash-2.05$ gcc -pthread
>     gcc: unrecognized option `-pthread'
>     gcc: no input files
>
> which seems to indicate you are right.  I am kind of surprised.  Some
> platforms to take -pthread, some -lpthread, so I am pretty sure it was
> specified by the original Solaris guy.

there are also platforms using -pthreads, -kthread, -Kthread, -mthreads,
-mt and --thread-safe ... with dependancies on other compiler flags like
-D_REENTRANT, -D_THREAD_SAFE, order dependencies (like need to check for
pthreads before -lpthread on AIX) and sometimes resulting in a different
compiler program called alltogether.


Jan

>
> OK, new template/solaris version applied to 7.4.X and head:
>
> ---------------------------------------------------------------------------
>
>
> if test "$GCC" != yes ; then
>   CC="$CC -Xa"            # relaxed ISO C mode
>   CFLAGS="-O -v"        # -v is like gcc -Wall
> fi
>
> # Pick right test-and-set (TAS) code.
> case $host in
>   sparc-*-solaris*)  need_tas=yes; tas_file=solaris_sparc.s ;;
>   i?86-*-solaris*)   need_tas=yes; tas_file=solaris_i386.s ;;
> esac
>
> THREAD_SUPPORT=yes
> NEED_REENTRANT_FUNCS=yes    # 5.6 2003-09-13
> THREAD_CPPFLAGS="-D_POSIX_PTHREAD_SEMANTICS"
> if test "$GCC" != yes
> then    THREAD_CPPFLAGS="$THREAD_CPPFLAGS -mt"
> fi
> THREAD_LIBS="-lpthread"
>


--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

>> bash-2.05$ gcc -pthread
>> gcc: unrecognized option `-pthread'
>> gcc: no input files
>>
>> which seems to indicate you are right.  I am kind of surprised.  Some
>> platforms to take -pthread, some -lpthread, so I am pretty sure it was
>> specified by the original Solaris guy.

> there are also platforms using -pthreads, -kthread, -Kthread, -mthreads,
> -mt and --thread-safe ... with dependancies on other compiler flags like
> -D_REENTRANT, -D_THREAD_SAFE, order dependencies (like need to check for
> pthreads before -lpthread on AIX) and sometimes resulting in a different
> compiler program called alltogether.

The compiler in question here is GCC.  The existing IF statement already
specified -lpthread for the Solaris compiler.  It was specifying -pthread
for GCC, which was incorrect - GCC says it is an unrecognized option.
Surely GCC on AIX isn't going to have the -pthread option, is it?  Don't
know - I've never run GCC on AIX...

I think the remaining outstanding question for Solaris is -D_THREAD_SAFE.
Based on your research, -D_REENTRANT is needed for errno to be defined
properly, so it was added.  But, -D_THREAD_SAFE is still not specified.  Is
it needed or not needed?

Wes