Bug#475101: obsolete linuxthreads requirement
Kurt Roeckx <kurt@roeckx.be> 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
Reply to: