Kurt Roeckx <[EMAIL PROTECTED]> writes: > On Fri, Apr 11, 2008 at 08:23:19AM +0200, Simon Josefsson wrote: >> >> Thanks. But does LinuxThreads need -D_REENTRANT today? The links to >> the gnulib list I gave suggested that it isn't necessary, but without >> knowing exactly what to test it is difficult to know for sure. > > I think that testing that errno is thread local instead of global is a > good test to see if it's needed.
Agreed. > I know that "extern int errno;" used to work on systems using > LinuxThreads, but that it fails to link on systems using NPTL. I believe one needs to use '#include <errno.h>' to be portable nowadays, at least according to: http://www.opengroup.org/onlinepubs/009695399/functions/errno.html > But even the errno.h from i386 sarge seems to use (*__errno_location ()). Right. > So it looks to me that _REENTRANT is only used to make some functions > like getlogin_r available. That is how I understand the situation as well. >> I don't know much about thread stuff, but my hope is that we could >> derive some concrete explanation of what breaks if you don't add >> -D_REENTRANT when building debian packages. That would make it possible >> to come back to this text later and evaluate whether the reasons for >> having the text are still valid. > > I think that on a Debian system using glibc using _REENTRANT isn't > needed if: > - You don't need specialy reentrant functions from libc; To be more precise: if you don't need the *.h prototype's for the specialy reentrant functions. > - Other libraries you're using have something in their include > files that change behaviour depending on _REENTRANT; Right. libxml2 may be one such candidate, at least it inspects _REENTRANT in /usr/include/libxml2/libxml/xmlversion.h. I'm not sure if its value matters though. > - The package you're building itself doesn't change change behaviour > depending on _REENTRANT. Right. > I think that libraries in Debian should never change behaviour based on > _REENTRANT. If a library can be build to either support threads or > not, it should be compiled to support threads. It might also want to > provide one that does and one that doesn't so that you can link to > either one, but I would like to discourage that, and the default library > should be the one that supports threads. And if it does provide 2 > libraries, the header files for both should be the same and not depend > on _REENTRANT. I think I agree here too, although I'm not as confident. In any case, I think we can safely assert that many libraries don't need -D_REENTRANT. The trade-off then is to compare the costs of forcing maintainers (via the policy) to build all libraries in Debian with a special flag against the costs of potentially running into some library that actually need the flag in order to not cause problems in a threaded environment. My general preference is to only do exceptions when they are known to be needed, and avoid bloating all software for the benefit of a few scenarios. Thus, I would prefer if in the (likely few) cases where setting -D_REENTRANT is required, that it is done explicitly only in those cases. I wouldn't want to change something like this at this time in the release cycle though. This discussion reinforced the rationale for my decision that GnuTLS should not set -D_REENTRANT when it is built. It doesn't use any reentrant functions, and its use of errno is thread safe since it accesses it via errno.h. There may be non-debian systems were it is needed, but I'd prefer to add it only on those platforms. /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
