Bodo Moeller <[EMAIL PROTECTED]>:
>> But doesn't -D_REENTRANT or -D_THREAD_SAFE usually also implicitly
>> assumes that one _links_ against the reentrant libc and this way
>> doing only half the way could cause problems?
> Well, at least for Linux (with glibc 2) and for Solaris I am pretty sure
> that the standard libc has no problems with this. I have no idea,
> though, how these things are handled on other systems.
> The standard library functions always call __errno_location (glibc) or
> ___errno (SunOS 5.6) to obtain a pointer to the instance of errno that
> they should use. As long as you don't spawn additional threads, this
> function always returns a pointer to the errno global variable, so use
> of *___errno() and of errno can be mixed.
Turns out that the Linux-specific parts of glibc 2.1 doesn't pay
attention to the standards in the first place and _always_ defines
errno to be that macro. So, unless (or until) there are also correct
versions of the library, -D_REENTRANT is not needed on Linux with
glibc. But earlier Linux libraries apparently behave correctly and
use the declaration "extern int errno" unless certain reserved symbols
have been defined (_POSIX_THREAD_SAFE_FUNCTIONS or _REENTRANT).
For SunOS 5.6 I can confirm that the library compiled with
-D_REENTRANT works as intended (and as expected) when threads are
used; my threaded program uses -lxnet -lpthread as the only linker
options, there's nothing to do about libc. And the -D_REENTRANT
OpenSSL library still works when threads are not used and a program
linked with it does not define _REENTRANT.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
