Building shared libraries with static C Run Time Libraries is a disaster waiting to happen on many platforms. It is simply something you should not do. Not just because of the problem you are describing but because the C Run Time Libraries might be from completely incompatible implementations. Perhaps from different vendors. (This is a frequent problem on OS/2 when people try to mix EMX and IBM run time libraries.)
If avoiding this problem is a goal of OpenSSL, then the only way to handle it is to never call a run time library function that works on a FILE * directly. Instead, all such calls must be made via callbacks to the application space in much the same way that we do for memory allocation and deallocation. Or applications must never create FILEs themselves and instead must use versions of fopen(), fclose(), ... which are provided by OpenSSL. > This is not a design flaw in the BIO. It is a requirement on Windows > that the DLLs be built with the same run-time library and threading > models as the application. > > > > Hard to believe it might by true. Nevertheless > > everything indicates there is a major design flaw > > in BIO: > > > > BIO sends FILE* pointer across dll boundary, causing > > crash of statically linked version of libeay32.dll. > > (At least on WINNT). To reproduce, modify the corresponding > > compiler switch to /MT and try enclosed tests. The crash > > is located inside the EnterCriticalSection API, since the dll > > incorrectly considers sent FILE* as FILEX structure after > > being unable to locate it in its own list of FILEs. > > > > This is caused by the fact, both exe and dll maintain its > > own copy of the run time library, hence FILE* from > > the exe cannot work inside the DLL. > > > > > > Jan Kuznik > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > Development Mailing List [EMAIL PROTECTED] > > Automated List Manager [EMAIL PROTECTED] > > Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/ Secured with MIT Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
