On dropping -D_REENTRANT -D_THREAD_SAFE

[Simon Josefsson-2]

For a long time configure.in has contained:

dnl In order to use the reentrant libc functions.
dnl I hope it is portable enough.
CFLAGS="${CFLAGS} -D_REENTRANT -D_THREAD_SAFE"
AM_CFLAGS="${CFLAGS}"

The problem with this is that disabling the default -O2 from builds,
which is typically done with 'make CFLAGS=-g', doesn't work.  I think we
could fix that problem by using:

CFLAGS="${CFLAGS} -D_REENTRANT -D_THREAD_SAFE"
AM_CFLAGS="${AM_CFLAGS} -D_REENTRANT -D_THREAD_SAFE"

But then I started to investigate why we need -D_REENTRANT
-D_THREAD_SAFE at all.  Glibc manual says:

 -- Macro: _REENTRANT
 -- Macro: _THREAD_SAFE
     If you define one of these macros, reentrant versions of several
     functions get declared.  Some of the functions are specified in
     POSIX.1c but many others are only available on a few other systems
     or are unique to GNU libc.  The problem is the delay in the
     standardization of the thread safe C library interface.

     Unlike on some other systems, no special version of the C library
     must be used for linking.  There is only one version but while
     compiling this it must have been specified to compile as thread
     safe.

Glibc features.h says:

...
   _GNU_SOURCE All of the above, plus GNU extensions.
   _REENTRANT Select additionally reentrant object.
   _THREAD_SAFE Same as _REENTRANT, often used by other systems.
...

However, grepping for _REENTRANT in /usr/include/* on my systems reveals
that it is only used for 'getlogin_r', which we aren't using anyway.

My conclusion is that -D_REENTRANT -D_THREAD_SAFE is not needed on glibc
systems.  Does anyone know of other systems that needs these defines to
work properly?

I'm inclined to remove the lines from configure.in.  If some other
system needs this to have working standard C/POSIX functions, we could
solve it via a gnulib module, I suppose.

Thoughts?

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Sam Varshavchik]

Simon Josefsson writes:

> My conclusion is that -D_REENTRANT -D_THREAD_SAFE is not needed on glibc
> systems.  Does anyone know of other systems that needs these defines to
> work properly?
>
> I'm inclined to remove the lines from configure.in.  If some other
> system needs this to have working standard C/POSIX functions, we could
> solve it via a gnulib module, I suppose.

You don't even need to do that at all. If someone needs these symbols, they
can simply set CPPFLAGS before running configure (the -D flags belong in
CPPFLAGS, rather than CFLAGS, in any case).




_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Sam Varshavchik <mrsam@...> writes:

> Simon Josefsson writes:
>
>> My conclusion is that -D_REENTRANT -D_THREAD_SAFE is not needed on glibc
>> systems.  Does anyone know of other systems that needs these defines to
>> work properly?
>>
>> I'm inclined to remove the lines from configure.in.  If some other
>> system needs this to have working standard C/POSIX functions, we could
>> solve it via a gnulib module, I suppose.
>
> You don't even need to do that at all. If someone needs these symbols,
> they can simply set CPPFLAGS before running configure (the -D flags
> belong in CPPFLAGS, rather than CFLAGS, in any case).

I have removed them.  Let's see if someone complains about it.

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Nikos Mavrogiannopoulos]

On Friday 04 January 2008, Simon Josefsson wrote:
> For a long time configure.in has contained:
>
> dnl In order to use the reentrant libc functions.
> dnl I hope it is portable enough.
> CFLAGS="${CFLAGS} -D_REENTRANT -D_THREAD_SAFE"

I believe these flags are used in solaris. Probably older systems require them
too.


regards,
Nikos


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Nikos Mavrogiannopoulos <nmav@...> writes:

> On Friday 04 January 2008, Simon Josefsson wrote:
>> For a long time configure.in has contained:
>>
>> dnl In order to use the reentrant libc functions.
>> dnl I hope it is portable enough.
>> CFLAGS="${CFLAGS} -D_REENTRANT -D_THREAD_SAFE"
>
> I believe these flags are used in solaris. Probably older systems
> require them too.

But does it have any effect for any functions we actually use?
libgnutls* uses very few POSIX/C89 functions that have thread-issues,
the only one I could find was that we use gmtime_r.

I checked on a solaris 5.10 machine, and the _REENTRANT symbol enables
prototypes for some functions like getlogin_r, ttyname_r, rand_r, and
actually also gmtime_r.  However, the gmtime_r prototype, and most other
prototypes, are also always declared if !_STRICT_STDC:

#if defined(__EXTENSIONS__) || \
        (!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
        (_POSIX_C_SOURCE - 0 >= 199506L) || defined(_REENTRANT)
extern struct tm *gmtime_r(const time_t *_RESTRICT_KYWD,
                        struct tm *_RESTRICT_KYWD);

So I think we are safe.  To make sure, I'll build the latest daily
snapshot and build it on this machine now..

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Simon Josefsson <simon@...> writes:

> So I think we are safe.  To make sure, I'll build the latest daily
> snapshot and build it on this machine now..

I built both 2.2.0 and 2.3.0 snapshot without problem.  There were no
differences in config.h due to this change.

There was, however, a problem with HUGE_VAL:

gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes -I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/tmp/jas//include -g -O2 -MT shared.o -MD -MP -MF .deps/shared.Tpo -c -o shared.o `test -f 'cfg/shared.c' || echo './'`cfg/shared.c
cfg/shared.c: In function `store_single_arg':
cfg/shared.c:727: error: wrong type argument to unary plus
cfg/shared.c:727: error: wrong type argument to unary minus

The line reads:

                        if (double_val == +HUGE_VAL || double_val == -HUGE_VAL)

It seems HUGE_VAL expands (gcc -E) into __builtin_huge_val, but I can't
find its definition.  It is probably a symbol defined in some library.

Replacing HUGE_VAL with HUGE worked, but I'm not sure if that is a good
idea...

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Sam Varshavchik]

Simon Josefsson writes:

> It seems HUGE_VAL expands (gcc -E) into __builtin_huge_val, but I can't
> find its definition.  It is probably a symbol defined in some library.

The __builtin symbols are recognized directly by gcc.



_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Florian Weimer-2]

* Simon Josefsson:

> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes -I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/tmp/jas//include -g -O2 -MT shared.o -MD -MP -MF .deps/shared.Tpo -c -o shared.o `test -f 'cfg/shared.c' || echo './'`cfg/shared.c
> cfg/shared.c: In function `store_single_arg':
> cfg/shared.c:727: error: wrong type argument to unary plus
> cfg/shared.c:727: error: wrong type argument to unary minus
>
> The line reads:
>
> if (double_val == +HUGE_VAL || double_val == -HUGE_VAL)

Looks like a GCC bug to me.  I can't reproduce this with:

gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)

--
Florian Weimer                <fweimer@...>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: [phone]
D-76133 Karlsruhe             fax: [phone]


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Florian Weimer <fweimer@...> writes:

> * Simon Josefsson:
>
>> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes -I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/tmp/jas//include -g -O2 -MT shared.o -MD -MP -MF .deps/shared.Tpo -c -o shared.o `test -f 'cfg/shared.c' || echo './'`cfg/shared.c
>> cfg/shared.c: In function `store_single_arg':
>> cfg/shared.c:727: error: wrong type argument to unary plus
>> cfg/shared.c:727: error: wrong type argument to unary minus
>>
>> The line reads:
>>
>> if (double_val == +HUGE_VAL || double_val == -HUGE_VAL)
>
> Looks like a GCC bug to me.  I can't reproduce this with:
>
> gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
> gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)

This was gcc 3.4.x and 4.0.3 on solaris 5.10, but on a machine that I
suspect doesn't have enough administrative TLC to have properly
installed tools.  So unless someone else reports the same issue, let's
ignore it.

FWIW, I had difficulties using the generated binaries on the machine
because they sucked up too much entropy from /dev/random.  Sigh.

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Albert Chin-78]

On Mon, Jan 07, 2008 at 10:12:13PM +0100, Simon Josefsson wrote:

> Florian Weimer <fweimer@...> writes:
>
> > * Simon Josefsson:
> >
> >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes -I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/tmp/jas//include -g -O2 -MT shared.o -MD -MP -MF .deps/shared.Tpo -c -o shared.o `test -f 'cfg/shared.c' || echo './'`cfg/shared.c
> >> cfg/shared.c: In function `store_single_arg':
> >> cfg/shared.c:727: error: wrong type argument to unary plus
> >> cfg/shared.c:727: error: wrong type argument to unary minus
> >>
> >> The line reads:
> >>
> >> if (double_val == +HUGE_VAL || double_val == -HUGE_VAL)
> >
> > Looks like a GCC bug to me.  I can't reproduce this with:
> >
> > gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
> > gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
>
> This was gcc 3.4.x and 4.0.3 on solaris 5.10, but on a machine that I
> suspect doesn't have enough administrative TLC to have properly
> installed tools.  So unless someone else reports the same issue, let's
> ignore it.

We see it with gcc-3.4.4 on Solaris 10/SPARC.

--
albert chin (china@...)


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Albert Chin <gnutls-dev@...> writes:

> On Mon, Jan 07, 2008 at 10:12:13PM +0100, Simon Josefsson wrote:
>> Florian Weimer <fweimer@...> writes:
>>
>> > * Simon Josefsson:
>> >
>> >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes -I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/tmp/jas//include -g -O2 -MT shared.o -MD -MP -MF .deps/shared.Tpo -c -o shared.o `test -f 'cfg/shared.c' || echo './'`cfg/shared.c
>> >> cfg/shared.c: In function `store_single_arg':
>> >> cfg/shared.c:727: error: wrong type argument to unary plus
>> >> cfg/shared.c:727: error: wrong type argument to unary minus
>> >>
>> >> The line reads:
>> >>
>> >> if (double_val == +HUGE_VAL || double_val == -HUGE_VAL)
>> >
>> > Looks like a GCC bug to me.  I can't reproduce this with:
>> >
>> > gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
>> > gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
>>
>> This was gcc 3.4.x and 4.0.3 on solaris 5.10, but on a machine that I
>> suspect doesn't have enough administrative TLC to have properly
>> installed tools.  So unless someone else reports the same issue, let's
>> ignore it.
>
> We see it with gcc-3.4.4 on Solaris 10/SPARC.

Indeed the problem seems real, however it seems to be a gcc bug:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933

A patch for gcc back-ported to 3.4.x is:

http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02123.html

I can't test the patch, but it seems to address the problem.

Does any of the suggested work-arounds work for you?  I.e., add the
following before the line containing "cfg+.h" in src/cfg/shared.c:

#define HUGE_VAL (__builtin_huge_val())

This work-around appears to work on the solaris 5.10 I have access to.

I'm not sure if we can detect this brokenness in a clean way, but
patches are welcome.  Otherwise, perhaps this message can serve as
sufficient documentation to work around this gcc problem.

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Albert Chin-79]

On Wed, Jun 25, 2008 at 12:44:31PM +0200, Simon Josefsson wrote:

> Albert Chin <gnutls-dev@...> writes:
>
> > On Mon, Jan 07, 2008 at 10:12:13PM +0100, Simon Josefsson wrote:
> >> Florian Weimer <fweimer@...> writes:
> >>
> >> > * Simon Josefsson:
> >> >
> >> >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes -I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/tmp/jas//include -g -O2 -MT shared.o -MD -MP -MF .deps/shared.Tpo -c -o shared.o `test -f 'cfg/shared.c' || echo './'`cfg/shared.c
> >> >> cfg/shared.c: In function `store_single_arg':
> >> >> cfg/shared.c:727: error: wrong type argument to unary plus
> >> >> cfg/shared.c:727: error: wrong type argument to unary minus
> >> >>
> >> >> The line reads:
> >> >>
> >> >> if (double_val == +HUGE_VAL || double_val == -HUGE_VAL)
> >> >
> >> > Looks like a GCC bug to me.  I can't reproduce this with:
> >> >
> >> > gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
> >> > gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
> >>
> >> This was gcc 3.4.x and 4.0.3 on solaris 5.10, but on a machine that I
> >> suspect doesn't have enough administrative TLC to have properly
> >> installed tools.  So unless someone else reports the same issue, let's
> >> ignore it.
> >
> > We see it with gcc-3.4.4 on Solaris 10/SPARC.
>
> Indeed the problem seems real, however it seems to be a gcc bug:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
>
> A patch for gcc back-ported to 3.4.x is:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02123.html
>
> I can't test the patch, but it seems to address the problem.

We have the patch.

> Does any of the suggested work-arounds work for you?  I.e., add the
> following before the line containing "cfg+.h" in src/cfg/shared.c:
>
> #define HUGE_VAL (__builtin_huge_val())
>
> This work-around appears to work on the solaris 5.10 I have access to.
>
> I'm not sure if we can detect this brokenness in a clean way, but
> patches are welcome.  Otherwise, perhaps this message can serve as
> sufficient documentation to work around this gcc problem.

It's only a problem with --std=gnu99. We just build without that
(ac_cv_prog_cc_c99=no) and things are ok.

--
albert chin (china@...)


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Albert Chin <gnutls-devel@...> writes:

>> Does any of the suggested work-arounds work for you?  I.e., add the
>> following before the line containing "cfg+.h" in src/cfg/shared.c:
>>
>> #define HUGE_VAL (__builtin_huge_val())
>>
>> This work-around appears to work on the solaris 5.10 I have access to.
>>
>> I'm not sure if we can detect this brokenness in a clean way, but
>> patches are welcome.  Otherwise, perhaps this message can serve as
>> sufficient documentation to work around this gcc problem.
>
> It's only a problem with --std=gnu99. We just build without that
> (ac_cv_prog_cc_c99=no) and things are ok.

Ok, great, so there are two workarounds for the compiler problem in case
someone else runs into this as well.

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel