[stunnel-users] Stunnel and DLL Hell
delaage.pierre at free.fr
Sat Oct 2 16:08:04 CEST 2010
I am not sure that static linking should be the good solution to this
Having many software linked statically to different versions of the same
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
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 :
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"
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
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
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
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 Browne
> cbrowne at cbcs-usa.com
> stunnel-users mailing list
> stunnel-users at mirt.net
More information about the stunnel-users