You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <Ma...@softlanding.com> on 2005/02/08 18:13:20 UTC

Problem with OpenSSL packaging on Windows

This is really a binary distribution issue, so perhaps you will not 
consider it your problem.

I have run into a problem from time to time where JavaHL will not load 
because an older, incompatible version of the OpenSSL DLL has been 
installed in the \Windows\System32 folder.  I have now run into two 
products that do this:

Crystal Reports
Cisco VPN Client

I had always thought these were just bad install programs, but I finally 
figured out part of the problem.  The versions of those DLL's that 
Subversion includes in it's binary distribution, or that it compiles from 
source, does not include a version resource in the DLL.  These other 
programs both include one in their version of the DLL.  So even if I put 
the newer version from Subversion into my System32 folder, it will still 
get overwritten by other install programs because to a standard Windows 
install program that compares the version it does not find one in our 
version of the DLL so it will just replace it.

I do not know what it takes to include a version resource in a DLL, but I 
will note that every other executable shipped with Subversion has one. 
Also, like I said, other products that ship these DLL's seem to have one 
in their version of the DLL.

Thanks

Mark




_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs. 
_____________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Problem with OpenSSL packaging on Windows

Posted by steveking <st...@gmx.ch>.
Mark Phippard wrote:
> This is really a binary distribution issue, so perhaps you will not 
> consider it your problem.
> 
> I have run into a problem from time to time where JavaHL will not load 
> because an older, incompatible version of the OpenSSL DLL has been 
> installed in the \Windows\System32 folder.  I have now run into two 
> products that do this:
> 
> Crystal Reports
> Cisco VPN Client

Add ZoneAlarm to that list too.
(which even more users have installed than the ones you've listed)

> I had always thought these were just bad install programs, but I finally 

They are!

> figured out part of the problem.  The versions of those DLL's that 
> Subversion includes in it's binary distribution, or that it compiles from 
> source, does not include a version resource in the DLL.  These other 
> programs both include one in their version of the DLL.  So even if I put 
> the newer version from Subversion into my System32 folder, it will still 
> get overwritten by other install programs because to a standard Windows 
> install program that compares the version it does not find one in our 
> version of the DLL so it will just replace it.

The problem here is not just that they overwrite your newer one with an 
older one - the 'newer' one isn't compatible anymore with the older 
ones. So if you install the dll which comes with Subversion into the 
System32 folder those other programs might stop working!

Quote from the INSTALL file:
  Note on shared libraries
  ------------------------

  Shared library is currently an experimental feature.  The only reason to
  have them would be to conserve memory on systems where several program
  are using OpenSSL.  Binary backward compatibility can't be guaranteed
  before OpenSSL version 1.0.

So you _must not_ put the openssl.dll in the windows or windows\system32 
path - NEVER!

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org