[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: MinGW libraries

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-08-18 05:34:34 CEST

Walter Nicholls wrote:

>
>> There's a dilemma here, known as "Windows DLL hell". Since we have no
>> control over installations, we can't prevent somebody from
>> _downgrading_ the installed DLLs. If the DLL names in svn-1.x are the
>> same as in svn-1.x+1, the newer stuff will break.
>
> No control over installations? I'm sure some overwhelming percentage
> of Windows users use the official Subversion MSI packages.

That's funny, given that there _are_ no official Subversion MSI packages. :)

> You can't prevent someone overwriting the dlls, but I don't think you
> need to worry about that scenario. If the official Sibversion
> installer installs C:\Program files\Subversion\bin\libsvn-1.dll then
> the end users heads be on it if they attempt to overwrite that with an
> earlier OR later version without using the corresponding installer.

A newer version should never be a problem. An older one could be.

> If you were to install the DLLs in c:\windows\system32 then DLL hell
> would be a problem. So don't do that!

Of course not. Perish the thought!

> I don't even think you need to include the major version number in the
> file name. Just looking in my C:\program files\Subversion\bin\
> directory, there is:
> intl.dll, intl3_svn.dll, libapr.dll, libapriconv.dll,
> libaprutil.dll ... svn.exe, svnadmin.exe, svndumpfilter.exe ...

See? You've already got mixed versions, "intl.dll" shouldn't be there. :)

And yes, we do need to include the major version in the name, at least.
That's project policy. In fact, it's APR's project policy too, and I
think it's a bug that APR's build doesn't put those names in the APR
DLLS....

> In fact the only files in here with any kind of version numbers in the
> filename are the BDB ones (libdb42.dll, libdb43.dll)

Indeed. And a good thing, too; because of that, it's impossible to load
the wrong BDB libary at runtime.

> I don't have any DLL hell problems with libapr.dll. And why isn't that
> "svn1.exe" or "svn-1.2.1.exe" then? I have a couple of scripts that
> parse svn.exe output, they could equally break if I downgraded say to
> svn 1.1

Executables are a different beast. The thing about DLLs is that, if
program A loads DLL D, and you then run program B that depends on a
(possibly quite different) DLL that also happens to be called D, B will
blindly try to link to the already-loaded D. Bang!

(O.K., this is not strictly true on newer versions of Windows, but it's
true for 99% of the installed base.)

> I can run two versions of Subversion by installing one in c:\program
> files\svn1.1 and another in c:\program files\svn1.2\ or the like

Exactly. And you can't do this safely with DLLs.

> The issue of MSVC6 vs VS.NET (vs Borland C++ builder vs...) is
> possibly a good one - although I would have expected that could be
> solved by defining the calling conventions properly. That may be more
> work thatn any wants to do though.

It's not about calling conventions, the problem is the runtime those
DLLs link to -- specifically, the format of the malloc heap. They're
incompatible.

> Perhaps the biggest problem is that with open-source products like
> this, people can create their own custom builds and break something
> that way.

So? We _want_ to support that, and I don't see it as being a problem --
therefore we'll put version numbers and runtome IDs in the DLL names,
thus avoiding possible clashes.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 18 05:35:35 2005

This is an archived mail posted to the Subversion Dev mailing list.