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
gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/bin/initdb'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/bin'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src'
gmake: *** [all] Error 2
$

Otherwise we don't pick up the threads library where the pthread_* routines
are defined.

(I sent the defines we need in src/template/unixware to Bruce already).



-- 
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
Thu, 18 Mar 2004 15:24:43 -0600
Larry Rosenman <ler@lerctr.org>
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


Thu, 18 Mar 2004 18:05:35 -0600 (CST)
Larry Rosenman <ler@lerctr.org>
Re: UnixWare/CVS Tip/initdb.c needs to use threads flags...
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

Thu, 18 Mar 2004 19:39:56 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: UnixWare/CVS Tip/initdb.c needs to use threads flags... 
--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
Thu, 18 Mar 2004 18:40:36 -0600
Larry Rosenman <ler@lerctr.org>
Re: UnixWare/CVS Tip/initdb.c needs to use threads
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

Thu, 18 Mar 2004 23:03:16 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: UnixWare/CVS Tip/initdb.c needs to use threads flags...
--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
Thu, 18 Mar 2004 22:47:37 -0600
Larry Rosenman <ler@lerctr.org>
Re: UnixWare/CVS Tip/initdb.c needs to use threads
--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
[370]     |0         |0         |NOTY |GLOB |0    |UNDEF 
|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
Thu, 18 Mar 2004 23:03:40 -0600
Larry Rosenman <ler@lerctr.org>
Re: UnixWare/CVS Tip/initdb.c needs to use threads
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

Fri, 19 Mar 2004 08:01:53 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: UnixWare/CVS Tip/initdb.c needs to use threads flags...
[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
Fri, 19 Mar 2004 07:39:18 -0600
Larry Rosenman <ler@lerctr.org>
Re: [HACKERS] UnixWare/CVS Tip/initdb.c needs to use threads
> [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

Fri, 19 Mar 2004 10:15:56 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] UnixWare/CVS Tip/initdb.c needs to use threads
--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
Fri, 19 Mar 2004 09:18:02 -0600
Larry Rosenman <ler@lerctr.org>
Re: [HACKERS] UnixWare/CVS Tip/initdb.c needs to use
--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
Fri, 19 Mar 2004 09:47:57 -0600
Larry Rosenman <ler@lerctr.org>
Re: [HACKERS] UnixWare/CVS Tip/initdb.c needs to use
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

Fri, 19 Mar 2004 10:55:53 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] UnixWare/CVS Tip/initdb.c needs to use threads
--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
Fri, 19 Mar 2004 09:57:30 -0600
Larry Rosenman <ler@lerctr.org>
Re: [HACKERS] UnixWare/CVS Tip/initdb.c needs to use
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

Fri, 19 Mar 2004 11:39:28 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] UnixWare/CVS Tip/initdb.c needs to use 
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

#-------------------------------------------------------------------------
#
# Makefile for src/bin (client programs)
#
# Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group
# Portions Copyright (c) 1994, Regents of the University of California
#
# $PostgreSQL: pgsql-server/src/bin/Makefile,v 1.41 2003/12/17 18:44:08 petere Exp $
#
#-------------------------------------------------------------------------

subdir = src/bin
top_builddir = ../..
include $(top_builddir)/src/Makefile.global

DIRS := initdb initlocation ipcclean pg_ctl pg_dump \
	psql scripts pg_config pg_controldata pg_resetxlog \
	pg_encoding

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

ifeq ($(with_tcl), yes)
	DIRS += pgtclsh
endif

all install installdirs uninstall depend distprep:
	@for dir in $(DIRS); do $(MAKE) -C $$dir $@ || exit; done

clean distclean maintainer-clean:
	-@for dir in $(DIRS); do $(MAKE) -C $$dir $@; done
Fri, 19 Mar 2004 11:46:20 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] UnixWare/CVS Tip/initdb.c needs to use
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

Index: src/bin/Makefile
===================================================================
RCS file: /cvsroot/pgsql-server/src/bin/Makefile,v
retrieving revision 1.41
diff -c -c -r1.41 Makefile
*** src/bin/Makefile	17 Dec 2003 18:44:08 -0000	1.41
--- src/bin/Makefile	19 Mar 2004 16:52:54 -0000
***************
*** 17,22 ****
--- 17,27 ----
  	psql scripts pg_config pg_controldata pg_resetxlog \
  	pg_encoding
  
+ # this platforms needs the thread compiler flag for all binaries to override libc
+ ifeq ($(PORTNAME), unixware)
+ CPPFLAGS += $(THREAD_CPPFLAGS)
+ endif
+ 
  ifeq ($(with_tcl), yes)
  	DIRS += pgtclsh
  endif
Fri, 19 Mar 2004 11:53:34 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] UnixWare/CVS Tip/initdb.c needs to use
Larry Rosenman wrote:
-- Start of PGP signed section.
> [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.

Clarification.  The flags are "-pthread" or "-K pthread", not -lpthread,
which is clearly a linker flag.

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

Mon, 22 Mar 2004 00:59:25 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] UnixWare/CVS Tip/initdb.c needs to use threads
Larry Rosenman wrote:
>  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.

Seems we have a few options for making threaded libpq on Unixware:

	o  remove thread-safe SIGPIPE code, which calls thread library

	o  create a threaded and non-threaded libpq library

	o  add a libpq function that enables threading, and do dynamic
linking of thread calls based on that function

	o  Add thread flags to all builds on that platform, including
the backend

	o  Add the ability to specify compile/link flags for everything
but the backend

As I remember, libcrypt used to be required by all libpq builds on
various platforms.   This seems to be a similar case.

I think the last option might be the best.  Somehow create different
cppflags/libs for the backend and non-backend programs.

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

Mon, 22 Mar 2004 01:12:03 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [PATCHES] UnixWare/CVS Tip/initdb.c needs to use threads
Bruce Momjian wrote:
> Larry Rosenman wrote:
> >  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.
> 
> Seems we have a few options for making threaded libpq on Unixware:
> 
> 	o  remove thread-safe SIGPIPE code, which calls thread library
> 
> 	o  create a threaded and non-threaded libpq library
> 
> 	o  add a libpq function that enables threading, and do dynamic
> linking of thread calls based on that function
> 
> 	o  Add thread flags to all builds on that platform, including
> the backend
> 
> 	o  Add the ability to specify compile/link flags for everything
> but the backend
> 
> As I remember, libcrypt used to be required by all libpq builds on
> various platforms.   This seems to be a similar case.
> 
> I think the last option might be the best.  Somehow create different
> cppflags/libs for the backend and non-backend programs.

One other option is to disable threads on this platform for 7.5 unless
we find another platforms that need this to use threads.  That is the
direction I will take for the moment.  If someone needs a threaded libpq
on this platform, then can enable threads, compile libpq alone, and
rename it with a thread extension.

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

Mon, 22 Mar 2004 09:52:54 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [PATCHES] UnixWare/CVS Tip/initdb.c needs to use threads
--On Monday, March 22, 2004 09:52:54 -0500 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Bruce Momjian wrote:
>> Larry Rosenman wrote:
>> >  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.
>>
>> Seems we have a few options for making threaded libpq on Unixware:
>>
>> 	o  remove thread-safe SIGPIPE code, which calls thread library
>>
>> 	o  create a threaded and non-threaded libpq library
>>
>> 	o  add a libpq function that enables threading, and do dynamic
>> linking of thread calls based on that function
>>
>> 	o  Add thread flags to all builds on that platform, including
>> the backend
>>
>> 	o  Add the ability to specify compile/link flags for everything
>> but the backend
>>
>> As I remember, libcrypt used to be required by all libpq builds on
>> various platforms.   This seems to be a similar case.
>>
>> I think the last option might be the best.  Somehow create different
>> cppflags/libs for the backend and non-backend programs.
>
> One other option is to disable threads on this platform for 7.5 unless
> we find another platforms that need this to use threads.  That is the
> direction I will take for the moment.  If someone needs a threaded libpq
> on this platform, then can enable threads, compile libpq alone, and
> rename it with a thread extension.
This will be a REGRESSION from 7.4.  I object STRENUOUSLY to this tack.

I want to see threads enabled for this platform since it is a threaded 
kernel.

What do we have to do to get there?   What code do I need to write for 
y'all?

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
Mon, 22 Mar 2004 11:14:59 -0600
Larry Rosenman <ler@lerctr.org>
Re: [PATCHES] UnixWare/CVS Tip/initdb.c needs to use
Larry Rosenman wrote:
> > One other option is to disable threads on this platform for 7.5 unless
> > we find another platforms that need this to use threads.  That is the
> > direction I will take for the moment.  If someone needs a threaded libpq
> > on this platform, then can enable threads, compile libpq alone, and
> > rename it with a thread extension.
>
> This will be a REGRESSION from 7.4.  I object STRENUOUSLY to this tack.
> 
> I want to see threads enabled for this platform since it is a threaded 
> kernel.
> 
> What do we have to do to get there?   What code do I need to write for 
> y'all?

I have disabled the threading option for that platform.  If someone else
wants to work with Larry and the community on a solution, feel free.  I
am done for now, no matter how much Larry "STRENUOUSLY" objects.

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

Mon, 22 Mar 2004 12:33:56 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [PATCHES] UnixWare/CVS Tip/initdb.c needs to use
--On Monday, March 22, 2004 12:33:56 -0500 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>> > One other option is to disable threads on this platform for 7.5 unless
>> > we find another platforms that need this to use threads.  That is the
>> > direction I will take for the moment.  If someone needs a threaded
>> > libpq on this platform, then can enable threads, compile libpq alone,
>> > and rename it with a thread extension.
>>
>> This will be a REGRESSION from 7.4.  I object STRENUOUSLY to this tack.
>>
>> I want to see threads enabled for this platform since it is a threaded
>> kernel.
>>
>> What do we have to do to get there?   What code do I need to write for
>> y'all?
>
> I have disabled the threading option for that platform.  If someone else
> wants to work with Larry and the community on a solution, feel free.  I
> am done for now, no matter how much Larry "STRENUOUSLY" objects.
>

Why so nasty?  If you didn't know, I was RIF'd from Internet America on 
Friday, and have some free time available to code for a bit.

I really, really, really want to see threads enabled for libpq for this 
platform, especially since SCO will be distributing it at some point in 
time.

What code do we need?

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
Mon, 22 Mar 2004 11:38:24 -0600
Larry Rosenman <ler@lerctr.org>
Re: [PATCHES] UnixWare/CVS Tip/initdb.c needs to use
Larry Rosenman <ler@lerctr.org> writes:
> I really, really, really want to see threads enabled for libpq for this
> platform, especially since SCO will be distributing it at some point in
> time.

I think very few of the folks on this list will see that as a reason
why they should expend any effort; more likely the opposite.

If you can fix it yourself in a reasonably non-intrusive way, we'll take
the patch ... that's about the extent of the cooperation you can expect.

			regards, tom lane

Mon, 22 Mar 2004 12:49:00 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCHES] UnixWare/CVS Tip/initdb.c needs to use 
Tom Lane wrote:
> Larry Rosenman <ler@lerctr.org> writes:
> > I really, really, really want to see threads enabled for libpq for this
> > platform, especially since SCO will be distributing it at some point in
> > time.
> 
> I think very few of the folks on this list will see that as a reason
> why they should expend any effort; more likely the opposite.
> 
> If you can fix it yourself in a reasonably non-intrusive way, we'll take
> the patch ... that's about the extent of the cooperation you can expect.

My big problem is that Larry doesn't have realistic balance in
determining how we are to spend our time.  Basically, if threading isn't
working in CVS for his platform, it is a crisis, and he thinks it should
be a crisis for us too, and will complain continuously until it is
fixed.  (This has been the pattern in the past.)  

I have no desire to work that way.  I, and Tom (I think) suggested that
we wait to see what other platforms need this kind of fix before
deciding on a solution.  However, Larry is obviously not satisfied with
that, so he is complaining.  Last I looked, I was here to work for the
community, based on the community priorities, not Larry's.

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

Mon, 22 Mar 2004 12:57:49 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [PATCHES] UnixWare/CVS Tip/initdb.c needs to use
--On Monday, March 22, 2004 12:49:00 -0500 Tom Lane <tgl@sss.pgh.pa.us> 
wrote:

> Larry Rosenman <ler@lerctr.org> writes:
>> I really, really, really want to see threads enabled for libpq for this
>> platform, especially since SCO will be distributing it at some point in
>> time.
>
> I think very few of the folks on this list will see that as a reason
> why they should expend any effort; more likely the opposite.
>
> If you can fix it yourself in a reasonably non-intrusive way, we'll take
> the patch ... that's about the extent of the cooperation you can expect.
would a dlsym-based solution be accepted?   I.E. wrap the pthread_* calls
in libpq, and if the real ones are present, use them, else return a static 
variable?


>
> 			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
Mon, 22 Mar 2004 12:07:36 -0600
Larry Rosenman <ler@lerctr.org>
Re: [PATCHES] UnixWare/CVS Tip/initdb.c needs to use 
Larry Rosenman <ler@lerctr.org> writes:
> --On Monday, March 22, 2004 12:49:00 -0500 Tom Lane <tgl@sss.pgh.pa.us>=20
> wrote:
>> If you can fix it yourself in a reasonably non-intrusive way, we'll take
>> the patch ... that's about the extent of the cooperation you can expect.

> would a dlsym-based solution be accepted?   I.E. wrap the pthread_* calls
> in libpq, and if the real ones are present, use them, else return a static=20
> variable?

I can't tell from that description if the idea meets the "non intrusive"
test or not.  How many places would you have to touch?  How exactly are
you going to tell "whether the real ones are present"?

			regards, tom lane

Mon, 22 Mar 2004 13:15:15 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCHES] UnixWare/CVS Tip/initdb.c needs to use 
--On Monday, March 22, 2004 13:15:15 -0500 Tom Lane <tgl@sss.pgh.pa.us> 
wrote:

> Larry Rosenman <ler@lerctr.org> writes:
>> --On Monday, March 22, 2004 12:49:00 -0500 Tom Lane
>> <tgl@sss.pgh.pa.us>=20 wrote:
>>> If you can fix it yourself in a reasonably non-intrusive way, we'll take
>>> the patch ... that's about the extent of the cooperation you can expect.
>
>> would a dlsym-based solution be accepted?   I.E. wrap the pthread_* calls
>> in libpq, and if the real ones are present, use them, else return a
>> static=20 variable?
>
> I can't tell from that description if the idea meets the "non intrusive"
> test or not.  How many places would you have to touch?  How exactly are
> you going to tell "whether the real ones are present"?


I'll gen up a patch this week and present it for review.

Basically the 3 pthread_* calls that were added for thread-safe pipes
would be wrapped, and dlsym returning NULL would mean the real ones are not 
present, per the note I got back from Dave Prosser of SCO, as well
as the paper Jonathan Schilling pointed me to, that I posted the URL to
on Friday before my world got rocked.

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
Mon, 22 Mar 2004 12:17:54 -0600
Larry Rosenman <ler@lerctr.org>
Re: [PATCHES] UnixWare/CVS Tip/initdb.c needs to use 