Whoa, A thing to keep in mind when you're mixing run-time libraries (and static linking to a DLL is mixing RTLs, even when you use the same (threading/etc.) flags for the main app build):
two risks: 1) malloc in one, free in other 2) the FILE * APIs (fopen, etc.) 3) file handl based APIs #1 is not [much of] a risk as openssl is nice & clean in this regard: everything it mallocs, it frees through its own cleanup APIs. #2 is a real risk: the static RTL that's attached to your DLL won't exactly understand the FILE* you pass to it from the main app. It depends on RTL implementations and usage patterns whether you get crashes or other undesirable behaviour that way, but the quick & fast way to prevent yourself from stumbling over this particular block is building the OpenSSL lib with all FILE* support removed, i.e. with the 'no-fp' configuration setting. (./config script) #3 is about passing 'int' [file] handles around, created in the main app, then used in the OpenSSL code, e.g. BIO subsystem. On unix, that's wouldn't be an issue, but on Windows, those 'int' handles are translated to system handles and the translation resides in the RTL code; having two RTLs 'sharing' file handles will cause trouble a la #2, because the one RTL does not have access to the translation table of the other. Successful compilation+linking doesn't necessarily mean you're going to get a working run-time. This is just a warning. The point is: go ahead, but tread carefully!! (It is commonly frowned upon to statically link RTLs (or other libraries) to DLLs and for good reason. It doesn't mean it can't work, but you must have intimate knowledge of both RTLs to prevent and/or resolve issues with such setups.) The healthier (if maybe somewhat more tedious at start) alternative is to build all DLLs and application using one compiler, linker and a common set of compiler and linker flags to ensure you're using the same (DLL-based) run-time library for every DLL and the EXE. I don't know about BBuilder, but the way to go would be to investagete which linker options are required to make the linker create DLLs for OpenSSL, then check the makefiles to see where you should drop those linker commandline options in there. You also probably need the .DEF files to make sure the linker gets those and will export those symbols from OpenSSL (crypto and ssl DLLs both); AFAIK the DEF files are generated as part of the batch file scripts on Win/DOS using perl and a definition file -- unfortunately I'm not much of a help there as I don't use those but have my own MSVC-project-based compile+link rigs here. On Mon, Oct 5, 2009 at 10:55 AM, Max Terentiev <maxterent...@mail.ru> wrote: > Hi, > > I recompile ntdll with /MT swith and yes, output dlls now > little bigger: > > libeay32.dll: 1 036 288 -> 1 122 304 > ssleay32.dll: 212 992 -> 274 432 > > Looks like something linked... -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
