Re: [PATCHES] [HACKERS] UnixWare/CVS Tip/initdb.c needs to use threads

2004-03-21 Thread Bruce Momjian
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 
 [EMAIL PROTECTED] 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
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [PATCHES] [HACKERS] UnixWare/CVS Tip/initdb.c needs to use

2004-03-19 Thread Larry Rosenman


--On Friday, March 19, 2004 09:18:03 -0600 Larry Rosenman [EMAIL PROTECTED] 
wrote:



--On Friday, March 19, 2004 10:15:56 -0500 Bruce Momjian
[EMAIL PROTECTED] wrote:
[moved to -patches because of the patch]

--On Friday, March 19, 2004 08:01:53 -0500 Bruce Momjian
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749


pgp0.pgp
Description: PGP signature


Re: [PATCHES] [HACKERS] UnixWare/CVS Tip/initdb.c needs to use

2004-03-19 Thread Tom Lane
Larry Rosenman [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] [HACKERS] UnixWare/CVS Tip/initdb.c needs to use

2004-03-19 Thread Bruce Momjian
Bruce Momjian wrote:
 Tom Lane wrote:
  Larry Rosenman [EMAIL PROTECTED] 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
  [EMAIL PROTECTED]   |  (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/Makefile17 Dec 2003 18:44:08 -  1.41
--- src/bin/Makefile19 Mar 2004 16:52:54 -
***
*** 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

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [PATCHES] [HACKERS] UnixWare/CVS Tip/initdb.c needs to use

2004-03-19 Thread Bruce Momjian
Larry Rosenman wrote:
  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.

But they currently CPPFLAGS.  They should be lib flags.

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

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] [HACKERS] UnixWare/CVS Tip/initdb.c needs to use

2004-03-19 Thread Larry Rosenman
On Fri, 19 Mar 2004, Bruce Momjian wrote:

 Larry Rosenman wrote:
   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.

 But they currently CPPFLAGS.  They should be lib flags.


they need to be passed to BOTH compiles and Links.



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

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match