UnixWare/CVS Tip/initdb.c needs to use threads flags...

On Thu, 18 Mar 2004, Larry Rosenman wrote:

I attempted(!) to compile up CVS Head, and if you --enable-thread-safety,
you need to include the THREADS stuff to cc:

gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/port'
cc -O -Kinline initdb.o -L../../../src/interfaces/libpq -lpq
-L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz
-lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm -lpgport
-o initdb
Undefined first referenced
symbol in file
pthread_getspecific libpq.so
pthread_key_create libpq.so
pthread_once libpq.so
pthread_setspecific libpq.so
UX:ld: ERROR: Symbol referencing errors. No output written to initdb
gmake[3]: *** [initdb] Error 1

I bring this up on PGHACKERS because unixware may not be the only
place we have to use the threads flags.

What is the concensus of the community?

LER

Larry Rosenman <ler@lerctr.org> writes:

What is the concensus of the community?

AFAICS, initdb should not need to depend on libpq in the first place;
it never makes a connection to a live postmaster. I think it would be
cleaner to get rid of that dependency instead of propagating thread junk
into initdb.

regards, tom lane

--On Thursday, March 18, 2004 19:39:56 -0500 Tom Lane <tgl@sss.pgh.pa.us>
wrote:

Larry Rosenman <ler@lerctr.org> writes:

What is the concensus of the community?

AFAICS, initdb should not need to depend on libpq in the first place;
it never makes a connection to a live postmaster. I think it would be
cleaner to get rid of that dependency instead of propagating thread junk
into initdb.

That's why I asked :)

LER

regards, tom lane

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Larry Rosenman wrote:

On Thu, 18 Mar 2004, Larry Rosenman wrote:

I attempted(!) to compile up CVS Head, and if you --enable-thread-safety,
you need to include the THREADS stuff to cc:

gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/port'
cc -O -Kinline initdb.o -L../../../src/interfaces/libpq -lpq
-L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz
-lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm -lpgport
-o initdb
Undefined first referenced
symbol in file
pthread_getspecific libpq.so
pthread_key_create libpq.so
pthread_once libpq.so
pthread_setspecific libpq.so
UX:ld: ERROR: Symbol referencing errors. No output written to initdb
gmake[3]: *** [initdb] Error 1

I bring this up on PGHACKERS because unixware may not be the only
place we have to use the threads flags.

What is the concensus of the community?

I tried removing the libpq link for initdb and got:

(3) gmake
gmake -C ../../../src/interfaces/libpq all
gmake[1]: Entering directory
`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/libpq'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory
`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/libpq'
gmake -C ../../../src/port all
gmake[1]: Entering directory
`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/port'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory
`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/port'
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations -O1 -Wall -Wmissing-prototypes
-Wmissing-declarations -Wpointer-arith -Wcast-align initdb.o
-L../../../src/port -L/usr/local/lib -L/usr/contrib/lib
-Wl,-rpath,/usr/local/pgsql/lib -O1 -Wall -Wmissing-prototypes
-Wmissing-declarations -Wpointer-arith -Wcast-align -lssl -lcrypto -lz
-lreadline -ltermcap -lgetopt -lcompat -lipc -ldl -lm -lutil -lpgport
-o initdb
initdb.o: In function `get_encoding_id':
initdb.o(.text+0x739): undefined reference to `pg_char_to_encoding'
initdb.o(.text+0x74b): undefined reference to `pg_valid_server_encoding'
initdb.o: In function `trapsig':
initdb.o(.text+0x2212): undefined reference to `pqsignal'
initdb.o: In function `main':
initdb.o(.text+0x2e69): undefined reference to `pqsignal'
initdb.o(.text+0x2e7b): undefined reference to `pqsignal'
initdb.o(.text+0x2e8a): undefined reference to `pqsignal'
initdb.o(.text+0x2e9c): undefined reference to `pqsignal'
initdb.o(.text+0x2ea8): more undefined references to `pqsignal' follow
gmake: *** [initdb] Error 1

I thought that once you include libpthread in libpq, that you don't have
to mention it again then you use libpq. Is your platform different
somehow in this regard?

I seem to remember this problem with libcrypt and libpq. Is this the
same problem?

I see that initdb is just the first of many /bin programs to be
compiled, so if we have to add the thread lib, we will have to do it for
all the bin programs. Yikes. Why wasn't this a problem for 7.4?

-- 
  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 Thursday, March 18, 2004 23:03:16 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

Larry Rosenman wrote:

On Thu, 18 Mar 2004, Larry Rosenman wrote:

I attempted(!) to compile up CVS Head, and if you
--enable-thread-safety, you need to include the THREADS stuff to cc:

gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/port'
cc -O -Kinline initdb.o -L../../../src/interfaces/libpq -lpq
-L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz
-lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm
-lpgport -o initdb
Undefined first referenced
symbol in file
pthread_getspecific libpq.so
pthread_key_create libpq.so
pthread_once libpq.so
pthread_setspecific libpq.so
UX:ld: ERROR: Symbol referencing errors. No output written to initdb
gmake[3]: *** [initdb] Error 1

I bring this up on PGHACKERS because unixware may not be the only
place we have to use the threads flags.

What is the concensus of the community?

I tried removing the libpq link for initdb and got:

(3) gmake
gmake -C ../../../src/interfaces/libpq all
gmake[1]: Entering directory
`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/libpq'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory
`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/libpq'
gmake -C ../../../src/port all
gmake[1]: Entering directory
`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/port'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory
`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/port'
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations -O1 -Wall -Wmissing-prototypes
-Wmissing-declarations -Wpointer-arith -Wcast-align initdb.o
-L../../../src/port -L/usr/local/lib -L/usr/contrib/lib
-Wl,-rpath,/usr/local/pgsql/lib -O1 -Wall -Wmissing-prototypes
-Wmissing-declarations -Wpointer-arith -Wcast-align -lssl -lcrypto -lz
-lreadline -ltermcap -lgetopt -lcompat -lipc -ldl -lm -lutil -lpgport
-o initdb
initdb.o: In function `get_encoding_id':
initdb.o(.text+0x739): undefined reference to `pg_char_to_encoding'
initdb.o(.text+0x74b): undefined reference to `pg_valid_server_encoding'
initdb.o: In function `trapsig':
initdb.o(.text+0x2212): undefined reference to `pqsignal'
initdb.o: In function `main':
initdb.o(.text+0x2e69): undefined reference to `pqsignal'
initdb.o(.text+0x2e7b): undefined reference to `pqsignal'
initdb.o(.text+0x2e8a): undefined reference to `pqsignal'
initdb.o(.text+0x2e9c): undefined reference to `pqsignal'
initdb.o(.text+0x2ea8): more undefined references to `pqsignal' follow
gmake: *** [initdb] Error 1

I thought that once you include libpthread in libpq, that you don't have
to mention it again then you use libpq. Is your platform different
somehow in this regard?

I seem to remember this problem with libcrypt and libpq. Is this the
same problem?

I see that initdb is just the first of many /bin programs to be
compiled, so if we have to add the thread lib, we will have to do it for
all the bin programs. Yikes. Why wasn't this a problem for 7.4?

7.4 had initdb as a Shell Script.
the 7.4.x libpq didn't have any pthread_* references in it, that I see
on my box.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

--On Thursday, March 18, 2004 22:47:39 -0600 Larry Rosenman
<ler@lerctr.org> wrote:

--On Thursday, March 18, 2004 23:03:16 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

I see that initdb is just the first of many /bin programs to be
compiled, so if we have to add the thread lib, we will have to do it for
all the bin programs. Yikes. Why wasn't this a problem for 7.4?

7.4 had initdb as a Shell Script.
the 7.4.x libpq didn't have any pthread_* references in it, that I see
on my box.

more info:

/home/ler/pg-prod/postgresql-7.4.2/src/interfaces/libpq:

$ grep pthread_ *.c
thread.c: * strerror(). Other operating systems use
pthread_setspecific()
thread.c: * and pthread_getspecific() internally to allow standard
library
thread.c: * use pthread_setspecific/pthread_getspecific() also have *_r
versions
thread.c: * getpwuid() calls pthread_setspecific/pthread_getspecific()
to return
thread.c: static pthread_mutex_t strerror_lock =
PTHREAD_MUTEX_INITIALIZER;
thread.c: pthread_mutex_lock(&strerror_lock);
thread.c: pthread_mutex_unlock(&strerror_lock);
thread.c: static pthread_mutex_t getpwuid_lock =
PTHREAD_MUTEX_INITIALIZER;
thread.c: pthread_mutex_lock(&getpwuid_lock);
thread.c: pthread_mutex_unlock(&getpwuid_lock);
thread.c: static pthread_mutex_t gethostbyname_lock =
PTHREAD_MUTEX_INITIALIZER;
thread.c: pthread_mutex_lock(&gethostbyname_lock);
thread.c: pthread_mutex_unlock(&gethostbyname_lock);
$ nm libpq.so | grep pthread
$

/home/ler/pg-dev/pgsql-server/src/interfaces/libpq: (7.5-dev):

$ nm libpq.so | grep pthread_
[271]: |0 |0 |NOTY |GLOB |0 |UNDEF |pthread_getspecific
|pthread_getspecific
[370]: |0 |0 |NOTY |GLOB |0 |UNDEF |pthread_key_create
|pthread_key_create
[421]: |0 |0 |NOTY |GLOB |0 |UNDEF |pthread_once
[434]: |0 |0 |NOTY |GLOB |0 |UNDEF |pthread_setspecific $ grep pthread_ *.c fe-connect.c: static pthread_once_t check_sigpipe_once = PTHREAD_ONCE_INIT; fe-connect.c: pthread_once(&check_sigpipe_once, check_sigpipe_handler); fe-print.c: pthread_setspecific(thread_in_send, "t"); fe-print.c: pthread_setspecific(thread_in_send, "f"); fe-secure.c:pthread_key_t thread_in_send; fe-secure.c: pthread_setspecific(thread_in_send, "t"); fe-secure.c: pthread_setspecific(thread_in_send, "f"); fe-secure.c: pthread_key_create(&thread_in_send, NULL); fe-secure.c: return (pthread_getspecific(thread_in_send) /* has it been set? */ && fe-secure.c: *(char *)pthread_getspecific(thread_in_send) == 't') ? true : false; thread.c: * strerror(). Other operating systems use pthread_setspecific() thread.c: * and pthread_getspecific() internally to allow standard library thread.c: * use pthread_setspecific/pthread_getspecific() also have *_r versions thread.c: * getpwuid() calls pthread_setspecific/pthread_getspecific() to return $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
|pthread_setspecific
$ grep pthread_ *.c
fe-connect.c: static pthread_once_t check_sigpipe_once =
PTHREAD_ONCE_INIT;
fe-connect.c: pthread_once(&check_sigpipe_once, check_sigpipe_handler);
fe-print.c:
pthread_setspecific(thread_in_send, "t");
fe-print.c: pthread_setspecific(thread_in_send, "f");
fe-secure.c:pthread_key_t thread_in_send;
fe-secure.c: pthread_setspecific(thread_in_send, "t");
fe-secure.c: pthread_setspecific(thread_in_send, "f");
fe-secure.c: pthread_key_create(&thread_in_send, NULL);
fe-secure.c: return (pthread_getspecific(thread_in_send) /* has it been
set? */ &&
fe-secure.c: *(char
*)pthread_getspecific(thread_in_send) == 't') ? true : false;
thread.c: * strerror(). Other operating systems use
pthread_setspecific()
thread.c: * and pthread_getspecific() internally to allow standard
library
thread.c: * use pthread_setspecific/pthread_getspecific() also have *_r
versions
thread.c: * getpwuid() calls pthread_setspecific/pthread_getspecific()
to return
$
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Larry Rosenman wrote:

I thought that once you include libpthread in libpq, that you don't have
to mention it again then you use libpq. Is your platform different
somehow in this regard?

I seem to remember this problem with libcrypt and libpq. Is this the
same problem?

I see that initdb is just the first of many /bin programs to be
compiled, so if we have to add the thread lib, we will have to do it for
all the bin programs. Yikes. Why wasn't this a problem for 7.4?

7.4 had initdb as a Shell Script.
the 7.4.x libpq didn't have any pthread_* references in it, that I see
on my box.

Ah, yes. We added the thread-local storage to handle SIGPIPE. The
problem is that initdb isn't the only place. If you comment out initdb
from the Makefile in src/bin, does the next make fail too? I bet it
does.

-- 
  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

[moved to -patches because of the patch]

--On Friday, March 19, 2004 08:01:53 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

Larry Rosenman wrote:

I thought that once you include libpthread in libpq, that you don't
have to mention it again then you use libpq. Is your platform
different somehow in this regard?

I seem to remember this problem with libcrypt and libpq. Is this the
same problem?

I see that initdb is just the first of many /bin programs to be
compiled, so if we have to add the thread lib, we will have to do it
for all the bin programs. Yikes. Why wasn't this a problem for 7.4?

7.4 had initdb as a Shell Script.
the 7.4.x libpq didn't have any pthread_* references in it, that I see
on my box.

Ah, yes. We added the thread-local storage to handle SIGPIPE. The
problem is that initdb isn't the only place. If you comment out initdb
from the Makefile in src/bin, does the next make fail too? I bet it
does.

Apparently, because of the way the wrappers work, having -lpthread on
libpq.so does NOT add it to the NEEDED list.

I made the following patch, and all compiles now:
Index: src/bin/initdb/Makefile
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/initdb/Makefile,v
retrieving revision 1.35
diff -u -r1.35 Makefile
--- src/bin/initdb/Makefile	23 Dec 2003 21:56:20 -0000	1.35
+++ src/bin/initdb/Makefile	19 Mar 2004 13:35:19 -0000
@@ -20,7 +20,7 @@
 all: submake-libpq submake-libpgport initdb

 initdb: $(OBJS) $(libpq_builddir)/libpq.a
-	$(CC) $(CFLAGS) $(OBJS) $(libpq) $(LDFLAGS) $(LIBS) -o $@
+	$(CC) $(CFLAGS) $(OBJS) $(libpq) $(LDFLAGS) $(LIBS) $(THREAD_LIBS) -o $@

 install: all installdirs
 	$(INSTALL_PROGRAM) initdb$(X) $(DESTDIR)$(bindir)/initdb$(X)
Index: src/bin/pg_dump/Makefile
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/Makefile,v
retrieving revision 1.44
diff -u -r1.44 Makefile
--- src/bin/pg_dump/Makefile	7 Feb 2004 07:20:12 -0000	1.44
+++ src/bin/pg_dump/Makefile	19 Mar 2004 13:35:19 -0000
@@ -25,13 +25,13 @@
 all: submake-libpq submake-libpgport submake-backend pg_dump pg_restore 
pg_dumpall

 pg_dump: pg_dump.o common.o pg_dump_sort.o $(OBJS) 
$(libpq_builddir)/libpq.a
-	$(CC) $(CFLAGS) pg_dump.o common.o pg_dump_sort.o $(OBJS) $(EXTRA_OBJS) 
$(libpq) $(LDFLAGS) $(LIBS) -o $@
+	$(CC) $(CFLAGS) pg_dump.o common.o pg_dump_sort.o $(OBJS) $(EXTRA_OBJS) 
$(libpq) $(LDFLAGS) $(LIBS) $(THREAD_LIBS) -o $@

 pg_restore: pg_restore.o $(OBJS) $(libpq_builddir)/libpq.a
-	$(CC) $(CFLAGS) pg_restore.o $(OBJS) $(EXTRA_OBJS) $(libpq) $(LDFLAGS) 
$(LIBS) -o $@
+	$(CC) $(CFLAGS) pg_restore.o $(OBJS) $(EXTRA_OBJS) $(libpq) $(LDFLAGS) 
$(LIBS) $(THREAD_LIBS) -o $@

 pg_dumpall: pg_dumpall.o dumputils.o $(libpq_builddir)/libpq.a
-	$(CC) $(CFLAGS) pg_dumpall.o dumputils.o $(EXTRA_OBJS) $(libpq) 
$(LDFLAGS) $(LIBS) -o $@
+	$(CC) $(CFLAGS) pg_dumpall.o dumputils.o $(EXTRA_OBJS) $(libpq) 
$(LDFLAGS) $(LIBS) $(THREAD_LIBS) -o $@

 .PHONY: submake-backend
 submake-backend:
Index: src/bin/pg_encoding/Makefile
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_encoding/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- src/bin/pg_encoding/Makefile	29 Nov 2003 19:52:05 -0000	1.16
+++ src/bin/pg_encoding/Makefile	19 Mar 2004 13:35:19 -0000
@@ -17,7 +17,7 @@
 all: submake-libpq submake-libpgport pg_encoding

 pg_encoding: $(OBJS)
-	$(CC) $(CFLAGS) $^ $(libpq) $(LDFLAGS) $(LIBS) -o $@
+	$(CC) $(CFLAGS) $^ $(libpq) $(LDFLAGS) $(LIBS) $(THREAD_LIBS) -o $@

 install: all installdirs
 	$(INSTALL_PROGRAM) pg_encoding$(X) $(DESTDIR)$(bindir)/pg_encoding$(X)
Index: src/bin/pgtclsh/Makefile
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/pgtclsh/Makefile,v
retrieving revision 1.43
diff -u -r1.43 Makefile
--- src/bin/pgtclsh/Makefile	19 Dec 2003 11:54:25 -0000	1.43
+++ src/bin/pgtclsh/Makefile	19 Mar 2004 13:35:20 -0000
@@ -33,10 +33,10 @@
 all: submake $(PROGRAMS)

 pgtclsh: pgtclAppInit.o
-	$(CC) $(CFLAGS) $^ $(libpgtcl) $(libpq) $(TCL_LIB_SPEC) $(TCL_LIBS) 
$(LDFLAGS) $(LIBS) -o $@
+	$(CC) $(CFLAGS) $^ $(libpgtcl) $(libpq) $(TCL_LIB_SPEC) $(TCL_LIBS) 
$(LDFLAGS) $(LIBS) $(THREAD_LIBS) -o $@

 pgtksh: pgtkAppInit.o
-	$(CC) $(CFLAGS) $^ $(libpgtcl) $(libpq) $(TK_LIB_SPEC) $(TK_LIBS) 
$(TCL_LIB_SPEC) $(LDFLAGS) $(LIBS) -o $@
+	$(CC) $(CFLAGS) $^ $(libpgtcl) $(libpq) $(TK_LIB_SPEC) $(TK_LIBS) 
$(TCL_LIB_SPEC) $(LDFLAGS) $(LIBS) $(THREAD_LIBS) -o $@

 .PHONY: submake
 submake:
Index: src/bin/psql/Makefile
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/Makefile,v
retrieving revision 1.40
diff -u -r1.40 Makefile
--- src/bin/psql/Makefile	9 Mar 2004 19:47:05 -0000	1.40
+++ src/bin/psql/Makefile	19 Mar 2004 13:35:20 -0000
@@ -27,7 +27,7 @@
 all: submake-libpq submake-libpgport psql

 psql: $(OBJS) $(libpq_builddir)/libpq.a
-	$(CC) $(CFLAGS) $(OBJS) $(libpq) $(LDFLAGS) $(LIBS) -o $@
+	$(CC) $(CFLAGS) $(OBJS) $(libpq) $(LDFLAGS) $(LIBS) $(THREAD_LIBS) -o $@

help.o: $(srcdir)/sql_help.h

Index: src/bin/scripts/Makefile
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/scripts/Makefile,v
retrieving revision 1.25
diff -u -r1.25 Makefile
--- src/bin/scripts/Makefile	29 Nov 2003 19:52:07 -0000	1.25
+++ src/bin/scripts/Makefile	19 Mar 2004 13:35:20 -0000
@@ -20,7 +20,7 @@
 all: submake-libpq submake-backend $(PROGRAMS)

 %: %.o
-	$(CC) $(CFLAGS) $^ $(libpq) $(LDFLAGS) $(LIBS) -o $@
+	$(CC) $(CFLAGS) $^ $(libpq) $(LDFLAGS) $(LIBS) $(THREAD_LIBS) -o $@

 createdb: createdb.o common.o dumputils.o 
$(top_builddir)/src/backend/parser/keywords.o
 createlang: createlang.o common.o print.o mbprint.o
Index: src/template/unixware
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v
retrieving revision 1.30
diff -u -r1.30 unixware
--- src/template/unixware	11 Feb 2004 21:44:06 -0000	1.30
+++ src/template/unixware	19 Mar 2004 13:35:21 -0000
@@ -24,5 +24,10 @@
   THREAD_CPPFLAGS="-K pthread"
 fi

-# tools/thread/thread_test must be run
+THREAD_SUPPORT=yes
 THREAD_CPPFLAGS="$THREAD_CPPFLAGS -D_REENTRANT"
+STRERROR_THREADSAFE=yes
+GETPWUID_THREADSAFE=yes
+GETHOSTBYNAME_THREADSAFE=yes
+THREAD_LIBS='-lpthread'
+
Index: src/tools/fsync/Makefile
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/tools/fsync/Makefile,v
retrieving revision 1.1
diff -u -r1.1 Makefile
--- src/tools/fsync/Makefile	18 Mar 2004 03:56:59 -0000	1.1
+++ src/tools/fsync/Makefile	19 Mar 2004 13:35:21 -0000
@@ -4,7 +4,7 @@
 #
 TARGET = test_fsync
 XFLAGS =
-CFLAGS = -g -Wall
+CFLAGS = -O
 LIBS =

$(TARGET) : test_fsync.o

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

[moved to -patches because of the patch]

--On Friday, March 19, 2004 08:01:53 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

Larry Rosenman wrote:

I thought that once you include libpthread in libpq, that you don't
have to mention it again then you use libpq. Is your platform
different somehow in this regard?

I seem to remember this problem with libcrypt and libpq. Is this the
same problem?

I see that initdb is just the first of many /bin programs to be
compiled, so if we have to add the thread lib, we will have to do it
for all the bin programs. Yikes. Why wasn't this a problem for 7.4?

7.4 had initdb as a Shell Script.
the 7.4.x libpq didn't have any pthread_* references in it, that I see
on my box.

Ah, yes. We added the thread-local storage to handle SIGPIPE. The
problem is that initdb isn't the only place. If you comment out initdb
from the Makefile in src/bin, does the next make fail too? I bet it
does.

Apparently, because of the way the wrappers work, having -lpthread on
libpq.so does NOT add it to the NEEDED list.

I made the following patch, and all compiles now:

Yes, I was afraid of that. Is there any way to make it work? If not,
evey libpq program you create will need -lpthread added.

-- 
  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 Friday, March 19, 2004 10:15:56 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

[moved to -patches because of the patch]

--On Friday, March 19, 2004 08:01:53 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

Larry Rosenman wrote:

I thought that once you include libpthread in libpq, that you don't
have to mention it again then you use libpq. Is your platform
different somehow in this regard?

I seem to remember this problem with libcrypt and libpq. Is this
the same problem?

I see that initdb is just the first of many /bin programs to be
compiled, so if we have to add the thread lib, we will have to do it
for all the bin programs. Yikes. Why wasn't this a problem for
7.4?

7.4 had initdb as a Shell Script.
the 7.4.x libpq didn't have any pthread_* references in it, that I see
on my box.

Ah, yes. We added the thread-local storage to handle SIGPIPE. The
problem is that initdb isn't the only place. If you comment out initdb
from the Makefile in src/bin, does the next make fail too? I bet it
does.

Apparently, because of the way the wrappers work, having -lpthread on
libpq.so does NOT add it to the NEEDED list.

I made the following patch, and all compiles now:

Yes, I was afraid of that. Is there any way to make it work? If not,
evey libpq program you create will need -lpthread added.

I think we need to mention if you --enable-thread-safety you MUST use
-lpthread on UnixWare, at least. I don't know about other platforms.

I'll ask the compiler guys, but I suspect we're going to have to do it this
way.

LER

--
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

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

--On Friday, March 19, 2004 09:18:03 -0600 Larry Rosenman <ler@lerctr.org>
wrote:

--On Friday, March 19, 2004 10:15:56 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

[moved to -patches because of the patch]

--On Friday, March 19, 2004 08:01:53 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

Larry Rosenman wrote:

I thought that once you include libpthread in libpq, that you don't
have to mention it again then you use libpq. Is your platform
different somehow in this regard?

I seem to remember this problem with libcrypt and libpq. Is this
the same problem?

I see that initdb is just the first of many /bin programs to be
compiled, so if we have to add the thread lib, we will have to do
it for all the bin programs. Yikes. Why wasn't this a problem for
7.4?

7.4 had initdb as a Shell Script.
the 7.4.x libpq didn't have any pthread_* references in it, that I
see on my box.

Ah, yes. We added the thread-local storage to handle SIGPIPE. The
problem is that initdb isn't the only place. If you comment out
initdb from the Makefile in src/bin, does the next make fail too? I
bet it does.

Apparently, because of the way the wrappers work, having -lpthread on
libpq.so does NOT add it to the NEEDED list.

I made the following patch, and all compiles now:

Yes, I was afraid of that. Is there any way to make it work? If not,
evey libpq program you create will need -lpthread added.

I think we need to mention if you --enable-thread-safety you MUST use
-lpthread on UnixWare, at least. I don't know about other platforms.

I'll ask the compiler guys, but I suspect we're going to have to do it
this way.

From the Compiler Guys:

The a.out (not any library) should be linked with -Kpthread (not
-lpthread).
This will force libthread to be linked in the right order relative to
libc, libC, networking libraries, etc.

In other words, the entire application either is or is not linked with
threads; it's not a property of an individual library.

SO, IF we are using the threads flags, we need to use them on ALL
libpq-using programs, ours or the users.

Not surprising.

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Larry Rosenman wrote:

I'll ask the compiler guys, but I suspect we're going to have to do it
this way.

From the Compiler Guys:

The a.out (not any library) should be linked with -Kpthread (not
-lpthread).
This will force libthread to be linked in the right order relative to
libc, libC, networking libraries, etc.

In other words, the entire application either is or is not linked with
threads; it's not a property of an individual library.

SO, IF we are using the threads flags, we need to use them on ALL
libpq-using programs, ours or the users.

Not surprising.

Is this problem with just the native compiler, or gcc too? Are enough
other platforms going to have this problem or do I make a
platform-specific hack for this?

-- 
  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 Friday, March 19, 2004 10:55:53 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

Larry Rosenman wrote:

I'll ask the compiler guys, but I suspect we're going to have to do it
this way.

From the Compiler Guys:

The a.out (not any library) should be linked with -Kpthread (not
-lpthread).
This will force libthread to be linked in the right order relative to
libc, libC, networking libraries, etc.

In other words, the entire application either is or is not linked with
threads; it's not a property of an individual library.

SO, IF we are using the threads flags, we need to use them on ALL
libpq-using programs, ours or the users.

Not surprising.

Is this problem with just the native compiler, or gcc too? Are enough
other platforms going to have this problem or do I make a
platform-specific hack for this?

GCC too, as it uses the native libraries. I am NOT familiar enough with
the other platforms to answer the question.

LER

--
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

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Larry Rosenman <ler@lerctr.org> writes:

In other words, the entire application either is or is not linked with
threads; it's not a property of an individual library.

SO, IF we are using the threads flags, we need to use them on ALL=20
libpq-using programs, ours or the users.

Yeek. This is an example of the sort of thing that makes people want to
build two versions of every library.

I'm not excited about doing that (at least not unless it pops up on more
platforms). It seems that what we have to do for Unixware is add
-Kpthread to LDFLAGS; is that correct?

regards, tom lane

Tom Lane wrote:

Larry Rosenman <ler@lerctr.org> writes:

In other words, the entire application either is or is not linked with
threads; it's not a property of an individual library.

SO, IF we are using the threads flags, we need to use them on ALL=20
libpq-using programs, ours or the users.

Yeek. This is an example of the sort of thing that makes people want to
build two versions of every library.

I'm not excited about doing that (at least not unless it pops up on more
platforms). It seems that what we have to do for Unixware is add
-Kpthread to LDFLAGS; is that correct?

I am attaching a new bin/Makefile that should fix it. The new code is:

# this platform needs the thread compiler flag for all binaries
# to override libc
ifeq ($(PORTNAME), unixware)
CPPFLAGS += "$THREAD_CPPFLAGS"
endif

Larry, does this fix it?

-- 
  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:

Tom Lane wrote:

Larry Rosenman <ler@lerctr.org> writes:

In other words, the entire application either is or is not linked with
threads; it's not a property of an individual library.

SO, IF we are using the threads flags, we need to use them on ALL=20
libpq-using programs, ours or the users.

Yeek. This is an example of the sort of thing that makes people want to
build two versions of every library.

I'm not excited about doing that (at least not unless it pops up on more
platforms). It seems that what we have to do for Unixware is add
-Kpthread to LDFLAGS; is that correct?

I am attaching a new bin/Makefile that should fix it. The new code is:

Sorry, here is the right patch.

-- 
  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 <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

It seems that what we have to do for Unixware is add
-Kpthread to LDFLAGS; is that correct?

Unusually, this platform doesn't have a THREAD_LIBS setting, only
THREAD_CPPFLAGS. so I have to use that.

If Larry quoted the Compiler Guys correctly, then that is *wrong*,
and we should put -Kpthread into THREAD_LIBS.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

It seems that what we have to do for Unixware is add
-Kpthread to LDFLAGS; is that correct?

Unusually, this platform doesn't have a THREAD_LIBS setting, only
THREAD_CPPFLAGS. so I have to use that.

If Larry quoted the Compiler Guys correctly, then that is *wrong*,
and we should put -Kpthread into THREAD_LIBS.

Yes, his patch ended up adding this to THREAD_LIBS, but
template/unixware has:

For gcc:

THREAD_CPPFLAGS="-pthread"

and for non-gcc:

THREAD_CPPFLAGS="-K pthread"

Larry, are these wrong?

-- 
  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 Fri, 19 Mar 2004, Bruce Momjian wrote:

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

It seems that what we have to do for Unixware is add
-Kpthread to LDFLAGS; is that correct?

Unusually, this platform doesn't have a THREAD_LIBS setting, only
THREAD_CPPFLAGS. so I have to use that.

If Larry quoted the Compiler Guys correctly, then that is *wrong*,
and we should put -Kpthread into THREAD_LIBS.

Yes, his patch ended up adding this to THREAD_LIBS, but
template/unixware has:

For gcc:

THREAD_CPPFLAGS="-pthread"

and for non-gcc:

THREAD_CPPFLAGS="-K pthread"

Larry, are these wrong?

Nope, those work, and should be passed to any libpq-using programs
link step if --enable-thread-safety is used.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749