Bug#475101: obsolete linuxthreads requirement

[Simon Josefsson <simon@josefsson.org>]

Russ Allbery <rra@debian.org> writes:

> Russ Allbery <rra@debian.org> writes:
>> Kurt Roeckx <kurt@roeckx.be> writes:
>
>>> So it looks to me that _REENTRANT is only used to make some functions
>>> like getlogin_r available.
>
>> I believe that's correct, and the discussion at the last DebConf reached
>> the same conclusion.  I think this bit in Policy is obsolete.  I already
>> closed a Lintian bug about it a while back.
>
>> You may separately need _REENTRANT to get prototypes, but using the right
>> feature test macros to get prototypes is a completely different issue and
>> I don't think we need to leave this in Policy just for that (otherwise,
>> we'd need to talk about GNU_SOURCE and whatnot as well, and I don't see a
>> need to go there right now).
>
>>> 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.  Could someone propose a wording change to Policy to say
>> what we really mean here rather than focusing on _REENTRANT?
>
> Here's an attempt at that.  I'm not sure if this says everything that
> needs to be said, but I'm not sure what else to say.
>
> I considered saying, as Kurt does above, that two libraries could be
> provided, one with thread support and one without, but this poses some
> serious problems because both libraries could be loaded into the same
> process space and then conflict.  Doing this properly requires symbol
> versioning or some other similar mechanism, and at that point I think
> we're getting into something that's too difficult and specific to describe
> in Policy.  I think I'd rather just let the "should" rather than "must"
> provide wiggle-room for that.
>
> Objections or seconds?

I don't think it should reference _REENTRANT any more for modern
GNU/Linux system like Debian.

LinuxThreads is an old thread implementation -- see
http://pauillac.inria.fr/~xleroy/linuxthreads/ -- that is not used any
more.  It is not even packaged in Debian.

The only need for _REENTRANT I know is OSF/1:

        # On OSF/1, the compiler needs the flag -D_REENTRANT so that it
        # groks <pthread.h>. cc also understands the flag -pthread, but
        # we don't use it because 1. gcc-2.95 doesn't understand -pthread,
        # 2. putting a flag into CPPFLAGS that has an effect on the linker
        # causes the AC_TRY_LINK test below to succeed unexpectedly,
        # leading to wrong values of LIBTHREAD and LTLIBTHREAD.
        CPPFLAGS="$CPPFLAGS -D_REENTRANT"

and Solaris:

    # Some systems optimize for single-threaded programs by default, and
    # need special flags to disable these optimizations. For example, the
    # definition of 'errno' in <errno.h>.
    case "$host_os" in
...
      solaris*) CPPFLAGS="$CPPFLAGS -D_REENTRANT" ;;

GNU/Linux doesn't need it as far as I have been able to determine.

getlogin_r appears to be declared by default now, /usr/include/unistd.h
says:

#if defined __USE_REENTRANT || defined __USE_POSIX199506
...
extern int getlogin_r (char *__name, size_t __name_len) __nonnull ((1));

But __USE_POSIX199506 is defined by default.

Lacking any real evidence of the need of _REENTRANT, I have long since
removed all uses of _REENTRANT in my projects (and gnulib) and these
projects are used in multi-threaded environments without problem.  On
the other hand, I know that some Debian packages re-add _REENTRANT.

Thus, I would suggest simply saying this:

	<p>
	  Libraries should be built with threading support and to be
	  thread-safe if the library supports this.
	</p>

Alternatively, provide the _real_ rationale for _REENTRANT.  I'm pretty
sure LinuxThreads isn't a valid rationale for it these days -- or am I
wrong?

/Simon

> diff --git a/policy.sgml b/policy.sgml
> index bad28af..1ffe148 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -7225,10 +7225,10 @@ INSTALL = install -s # (or use strip on the files in debian/tmp)
>            for C files) will need to be compiled twice, for the normal
>            case. 
>          </p>
> +
>  	<p>
> -	  You must specify the gcc option <tt>-D_REENTRANT</tt>
> -	  when building a library (either static or shared) to make
> -	  the library compatible with LinuxThreads.
> +	  Libraries should be built with threading support and to be
> +	  thread-safe if the library supports this.
>  	</p>
>  
>          <p>