Re: -DREENTRANT
On Wed, Apr 28, 1999 at 12:27:49PM +0200, Niels Poppe wrote: Ulrich Drepper wrote: [EMAIL PROTECTED] (Bodo Moeller) writes: 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. Somebody who has no clue about these things shouldn't make such comments. Errno is explicitly *always* allowed to be a macro and _REENTRANT is not defined in any standard. So, everything you wrote is completely wrong. Excuse me for possibly being clueless on this. Observing openssl libraries linked against glibc-2.0.7 I see the following: compiling with -D_REENTRANT -DTHREADS generates symbol U __errno_location compiling without these generates symbol U errno The definition of __errno_location is in libc.so.6 as as 'weak' symbol, and also in libpthread.so.0 as an 'absolute' symbol. Therefore linking applications with openssl without -lpthread will take the definition in libc, but -lpthread will overrride this (with the thread-specific value?). I don't have glibc 2.1 around, so I can't comment on that but for normal linux compilations I'd say making thread-safe libraries should be the default. That is, *with* -D_REENTRANT. Yes, I think so. Ulrich (of course?) is absolutely right that even in standard C without extensions errno need not be a variable. I don't know where I got the idea that the function-calling macro is is not legal for standard C. But often, _REENTRANT is necessary to get the definition that works for threads (e.g. for SunOS 5.6, and according to your observations also for glibc-2.0.7 on Linux; and the LinuxThreads library's FAQ is full of warnings that one never should forget to define it). I have no idea whether the pthreads *specification* comments on whether you may have to define special preprocessor symbols to use pthreads. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: -DREENTRANT
On Sun, Apr 25, 1999 at 02:38:48PM +0200, Ralf S. Engelschall wrote: I think we should by default define _REENTRANT or _THREAD_SAFE or any other system-dependent macros that are needed to get a library that can be used in multi-threaded programs. (This means, for example, that errno is not a variable, but a macro of the form (*__errno_location()), which uses a thread-local errno location -- errno for the main thread, something different for the other ones). At least when the library is installed to standard locations, it probably can lead to very confusing results if it all depends on whether one used "./config -D_REENTRANT" before compiling and installing the library. 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. Apart from providing additional function prototypes for thread-safe programs, defining _REENTRANT also changes macro definitions for things like putc (glibc) or prevents such macros from being defined (SunOS) -- the *function* in libc is always suitable for both cases, with -D_REENTRANT and without it. What about adding a new entry to each Configure definition that contains the appropriate -D... for systems where this is known to work and some dummy string for others, so that the user can be warned that in order to create a library which can be used with threads, they should look up in their system's documentation any additional compiler options that may be needed? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: -DREENTRANT
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]
