Hello, I am not sure that static linking should be the good solution to this problem. Having many software linked statically to different versions of the same library could lead to other problems (if they are interacting). At least, with a few search on the system and trivial properties check, it is "easy" to have a clear sight of the situation of your platform.

From an integrator point of view, I agree anyway that it is useful 1/ to KNOW what version of the library has been used at compile time (and is thus expected at exec time), 2/ to have the means to know what versions are available on the system, and 3/ to have the mean to CHOSE what version to use at execution time.

Stunnel is involved only in the first point.

All this 3 questions have trivial answers : 1/- See log of stunnel to know the library version used at compile time See also the changelog page to have this info : http://stunnel.mirt.net/?page=ChangeLog_sdf

2/ Windows search is now a mess but anyway finding some files is "possible". More usefully, "msinfo32", in the "Loaded Modules" list, will show you each copy of a library that are loaded into the system, but unfortunately not giving the loading program.

More simply : cd c:\ and then dir /a /b /s libeay32.dll will give you rapidly the different locations of the file you are searching for.

Some more tips and tools here : "Escape from DLL Hell with Custom Debugging and Instrumentation Tools and Utilities" http://msdn.microsoft.com/en-us/magazine/bb985842.aspx

3/ Yes you have the choice : by either having only one version of the dll on your system (typically in c:\windows), thus deleting all the others, OR by having a copy of the desired dll in the same folder as each executable of interest. The latter is done preferably, at least because some programs require a specific version, just because they have been validated vs that version (ie Quality Assurance reason): This is WHY you have so many copies of the same lib on your system... See more explanations here : Dynamic-Link Library Search Order http://msdn.microsoft.com/en-us/library/ms682586(v=VS.85).aspx

I recognize that my suggestions place the responsibility of dll consistency on the admin of the platform, instead of on the "installer" provider that could/should check and warns about potential conflict at install time.

Finally, I do not think that the problem is "dynamic linking" in itself, but just "proper checking" or "proper location" at install time, and "proper administration" of the software environment. And just because of the fact that some versions of a software has been validated with a specific version of the dll, it is almost mandatory that each sw places a copy of its critical dll in its own directory.

This is what is done by stunnel on win32, so there MUST not be any dll problem with it. Other examples : PostgresQL, OpenOffice 3 and Apple iTunes all install their own copy of ssleay32.dll in their own directory.

If there is problem, it comes from installers that install "their version of some" dll directly in c:\windows (something that MS products are well known to do), and/or by dll that break their interface or implementation from version to version (such dll should not be installed in common locations, of course).

Pierre Delaage

Le 30/09/2010 15:33, Carter Browne a écrit :

I just had an upgrade issue going from stunnel 4.32 (using the openssl 0.9.8x libraries) and stunnel 4.34 (using the openssl 1.0.0x libraries). I'm using the CAPATH option and verify = 2 to verify connections. The openssl group changed the hash algorithm between 0.9.8 and 1.0.0 so that the certificates have to have a different name (this is a Windows installation, so no linked names). When I initially converted I has two copies of the names, one using the old hash and one using the new hash and everything worked perfectly. However, after cleaned up the directories and removed the old hash names, things began to fail. Eventually I could not make any connections to the system running stunnel 4.34. Eventually, it occurred to me to check for multiple versions of the SSLEAY32.DLL and the system and there were a number of copies. For whatever reason, the 0.9.8x version got loaded first and so the 1.0.0x hash names were not recognized.

This explanation is a long winded request for having the option of having a statically linked version of stunnel for Windows. I have about 10 systems running stunnel 4.34 and all but this one worked properly. However, having the vagaries of which version of SSLEAY32 gets loaded by Windows first determining the correct operation of the system is an uncertainty that it would be very good to live without.

Thanks for the consideration.

Carter

Carter Browne CBCS [email protected] 781-721-2890

---

stunnel-users mailing list [email protected] http://stunnel.mirt.net/mailman/listinfo/stunnel-users