openldap-bugs

openldap-bugs@openldap.org

1 participants
20995 discussions

Re: (ITS#4981) Try -lpthread before -pthread
by kurt＠OpenLDAP.org 24 May '07

24 May '07

On May 23, 2007, at 10:16 PM, rra(a)stanford.edu wrote: > libtool does not pass -pthread through Our libtool does. But gcc might not do the right thing with it. In that case, it's a gcc bug which should be reported to the gcc folks. I believe using -lpthread over -pthread will cause more problems than its worth. That is, the problems caused by the missing link on some platforms is not nearly as bad as the caused by using -lc instead of -lc_r on other platforms. -- Kurt

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

rra(a)stanford.edu writes: > This issue, ITS#4982, is that no threading flags (not -pthread, not > -lpthread, not anything) are passed into the final link line of libldap_r, > as near as I can tell. Right. grepping make >& make.out shows no thread switch in the command line which builds libldap_r.so. Adding the ITS#4982 patch (and not ITS#4981), I got 4 '-pthread's in a row, which should be enough:-) -- Regards, Hallvard

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by rra＠stanford.edu 24 May '07

24 May '07

Kurt Zeilenga <kurt(a)OpenLDAP.org> writes: > libtool should properly handle -pthread. If it doesn't, that should be > fixed instead of kludging things up with -lpthread. -pthread tells gcc > to do the right thing. The right thing might not be to link in > -lpthread. (On some versions of FreeBSD, the right think is -lc_r.) > -pthread also might do more than link in a library. > As OpenLDAP includes its own copy of libtool, a local fix can be > provided until the upstream fixes it right. I think the above was meant for ITS #4981? This issue, ITS#4982, is that no threading flags (not -pthread, not -lpthread, not anything) are passed into the final link line of libldap_r, as near as I can tell. It's possible that I'm reading the makefile wrong and this has been fixed in some other way since the Debian patch had been applied, but libraries/libldap_r/Makefile.in contains: UNIX_LINK_LIBS = $(LDAP_LIBLBER_LA) $(AC_LIBS) $(SECURITY_LIBS) and build/lib-shared.mk has: $(LIBRARY): version.lo $(LTLINK_LIB) -o $@ $(OBJS) version.lo $(LINK_LIBS) including only LINK_LIBS, and not the regular LIBS variable (which is what includes LTHREAD_LIBS via XXXLIBS). It could be that I'm missing some contribution to LTLINK_LIB handled by the threading macros, though. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by kurt＠OpenLDAP.org 24 May '07

24 May '07

libtool should properly handle -pthread. If it doesn't, that should be fixed instead of kludging things up with -lpthread. -pthread tells gcc to do the right thing. The right thing might not be to link in - lpthread. (On some versions of FreeBSD, the right think is -lc_r.) -pthread also might do more than link in a library. As OpenLDAP includes its own copy of libtool, a local fix can be provided until the upstream fixes it right. -- Kurt On May 24, 2007, at 1:25 AM, rra(a)stanford.edu wrote: > Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> writes: >> Hallvard B Furuseth writes: > >>> Is this the second half of the Debian patch you posted in >>> ITS#4981 - so >>> it'd be wrong to apply one one of these patches? > >> Sorry, "wrong to apply _only_ one of". > >> (I.e. does ITS#4981 introduce breakage which ITS#4982 fixes?) Maybe >> everything worked well before we switched to libtool... > > No, they should be independent, I think. I believe that the > rationale for > 4982 is still correct; if you use pthread functions, you need to > explicitly link against the library to avoid getting unversioned > references. Unversioned references will *normally* not cause a > problem, > so they're a bit of a time bomb. They keep working fine right up > until > the library makes an incompatible change in the data structures, > and then > they break. > > -- > Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/ > ~eagle/> > >

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by rra＠stanford.edu 24 May '07

24 May '07

Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> writes: > Hallvard B Furuseth writes: >> Is this the second half of the Debian patch you posted in ITS#4981 - so >> it'd be wrong to apply one one of these patches? > Sorry, "wrong to apply _only_ one of". > (I.e. does ITS#4981 introduce breakage which ITS#4982 fixes?) Maybe > everything worked well before we switched to libtool... No, they should be independent, I think. I believe that the rationale for 4982 is still correct; if you use pthread functions, you need to explicitly link against the library to avoid getting unversioned references. Unversioned references will *normally* not cause a problem, so they're a bit of a time bomb. They keep working fine right up until the library makes an incompatible change in the data structures, and then they break. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

Hallvard B Furuseth writes: > Is this the second half of the Debian patch you posted in ITS#4981 - so > it'd be wrong to apply one one of these patches? Sorry, "wrong to apply _only_ one of". (I.e. does ITS#4981 introduce breakage which ITS#4982 fixes?) Maybe everything worked well before we switched to libtool... -- Regards, Hallvard

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

rra(a)stanford.edu writes: > Since 2.2.23, Debian has been carrying the following patch to the libldap_r > build process to explicitly link the library against the thread libraries. > (...) Is this the second half of the Debian patch you posted in ITS#4981 - so it'd be wrong to apply one one of these patches? -- Regards, Hallvard

1 0

Re: (ITS#4981) Try -lpthread before -pthread
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

rra(a)stanford.edu writes: > (...) libtool does not pass -pthread through, -lpthread seems > to work though. > (...) > + OL_PTHREAD_TRY([-lpthread], [ol_cv_pthread_lpthread]) > OL_PTHREAD_TRY([-pthread], [ol_cv_pthread_pthread]) > (...) This may be correct for Debian, but looks dubious as a general patch. On other systems that have a thread compiler switch it may be wrong to link the thread library "by hand" and omit the compiler switch, otherwise what's the compiler switch for? Their comments seem to indicate libtool is a better place to fix it. An OpenLDAP patch would likely need some 'if <debian>' code. (Note, I do not know Debian, nor specifics about differing Linux variants.) -- Regards, Hallvard

1 0

Re: (ITS#4983) libldap_r/tls.c compile failure
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

kurt(a)OpenLDAP.org writes: > tls.c: In function `tls_thread_self': > tls.c:412: error: invalid operands to binary / > tls.c:415: warning: comparison between pointer and integer Well, that was quick... my tls.c rev 1.154 patch, tls_thread_self(), deliberately causes that for non-integer thread types. I wanted feedback from systems where that happens, since the OpenSSL doc says such systems are rare and this code can break there. The CRYPTO_set_id_callback manpage (from openssl/doc/crypto/threads.pod) says the function expects an integer thread ID, but that the function is not needed if getpid() returns different answers for different threads. And that this may be dangerous to relay on because one might compile a program on a machine where this is true and then run it on a machine where it is false. Anyway, possibly the correct fix is to not call this function on FreeBSD, it depends on getpid(). I have no idea. But since it presumably worked before: The simplest fix is to just remove the 'ok' and 'Check' code. But then we can again silently compile to bad code when the thread type is not an integer. Next simplest: simplify the 'ok' check to: enum { ok = sizeof(ldap_pvt_thread_t) <= sizeof(long) }; which will still let us know of systems where the conversion to ulong clearly loses data. Not quite a safe, since pointer<->integer conversions can do who-knows-what. But I guess OpenLDAP depends on those elsewhere. (Can sizeof(long) be < sizeof(pointer) on FreeBSD?) Also in any case cast tls_thread_self()'s return value to u.long. -- Regards, Hallvard

1 0

(ITS#4983) libldap_r/tls.c compile failure
by kurt＠OpenLDAP.org 24 May '07

24 May '07

Full_Name: Kurt Zeilenga Version: HEAD OS: FreeBSD RELENG_6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.182.55.218) Submitted by: kurt /bin/sh ../..//libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLDAP_R_COMPILE -I./../libldap -I/usr/local/include -I/usr/pkg/include/db44 -I/usr/pkg/include -DLDAP_LIBRARY -c tls.c cc -g -O2 -I../../include -I../../include -DLDAP_R_COMPILE -I./../libldap -I/usr/local/include -I/usr/pkg/include/db44 -I/usr/pkg/include -DLDAP_LIBRARY -c tls.c -fPIC -DPIC -o .libs/tls.o tls.c: In function `tls_thread_self': tls.c:412: error: invalid operands to binary / tls.c:415: warning: comparison between pointer and integer tls.c:415: error: enumerator value for `ok' not integer constant tls.c:416: error: negative width in bit-field `dummy' tls.c:416: error: size of array `Check' is negative tls.c:418: warning: return makes integer from pointer without a cast

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs