Hi Albe, On Mon, 18 Dec 2006, Albe Laurenz wrote: > Date: Mon, 18 Dec 2006 09:31:35 +0100 > From: Albe Laurenz <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr, Tom Lane <[EMAIL PROTECTED]> > Cc: pgsql-hackers list <pgsql-hackers@postgresql.org> > Subject: RE: [HACKERS] unixware and --with-ldap > > >>> If libldap_r.so does require the same libs, please add > $EXTRA_LDAP_LIBS > >>> to the 'LDAP_LIBS_FE="-lldap_r"' line as well. > >> > >> Actually, I did that in the patch-as-committed. It seems to me that > >> it's probably harmless even if not needed. > > > > I have tried --with-thread-safety and configure fails on ldap check > > because for some reason CTHREAD_FLAGS (-Kpthread for UW) is missing > > on compile command, although present before that. I can't find why > > You mean PTHREAD_FLAGS, right? > Nope,I mean PTHREAD_CFLAGS witch is defined in src/templates/unixware > If it is present in line 1118, it should also be present in line 1133. > > Can you verify that the part on configure.in between 1065 and 1118, > -Kpthread is correctly set on Unixware? > It is defined, my guts felling is that AC_SUBSTs lines 1470,1471 do something weird. > If not, thread support for Unixware is probebly broken. > It is, because when searching for ldap_r succeeds by forcing PTHREAD_CFLAGS to be used, configure still fails when testing for thread safety compiling src/test/thread/thread_test.c.
This fails because unixware's sigwait has only one arg although (according to doc you can see at http://www.pyrenet.fr:8458) it's thread safe... > If yes, something strange is going on. > indeed > Yours, > Laurenz Albe > Best regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr ------------------------------------------------------------------------------ Make your life a dream, make your dream a reality. (St Exupery) ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
