> errno is stored in Thread Local Storage (TLS). You can't link to the > global errno anymore.
For a single-threaded process, there is no distinction between thread-local storage and a global variable. For a multi-threaded process, there is. The same code can have a different semantic meaning depending upon whether the process is single-threaded or multi-threaded. > Using "extern int errno" will actually result in a linking error: > /usr/bin/ld: errno: TLS definition in /lib/libc.so.6 section > .tbss mismatches non-TLS reference My point was simply that there is a difference between single-threaded and multi-threaded compilation. In one case, 'errno' refers to a variable that is process global (since there is only one thread). In the other case, it does not. That these two different semantics are implemented by the same code doesn't change the fact that the semantics are different. In fact, it makes the important point that the semantics of code can be changed by whether the process is single-threaded or multi-threaded. On many Linux distributions, it is perfectly acceptable to do the following: #ifdef _REENTRANT // inefficient thread-safe code #else // more efficient code that assumes 'errno' is process-global #endif This is because many distributions only guarantee POSIX compliance if you specify '-pthread' and '-pthread' always defines _REENTRANT. You have to follow the rules if you want the platform to follow the rules. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
