On Sat, Jan 10, 2009 at 3:58 PM, David Cournapeau <cournape@gmail.com> wrote:
> On Sun, Jan 11, 2009 at 4:59 AM, Sturla Molden <sturla@molden.no> wrote:
>>>>> Microsoft real answer to DLL hell is manifest files (address and
>>> version of a DLL), but it cannot be applied everywhere :(
>>> Does COM handle DLL versions ?
>>>> The idea is that a DLL is not just identified by a name, but by a number
>> (the CLSID). The CLSID is stored in the registry and is looked up to get
>> the fully qualified path of the DLL.
>> But what happens when you can't write to the registry ? Or is this per user ?
>>> The rules of COM specified that the
>> CLSID should change whenever the version of the DLL changed.
>> Unfortunately, developers broke this rule, so DLL hell persisted. But if
>> the developer i honest and complies with this, COM does not not produce
>> DLL Hell.
>>>http://msdn.microsoft.com/en-us/library/ms973843.aspx#dplywithnet_sharing>> It does not sound like COM is a good idea - according to MSDN's own
> word, COM is responsible for DLL Hell. I actually quite like the GAC
> principle - I think it would be nice for python itself to have
> something similar. But AFAIK, it is not possible to use this for
> unmanaged code, without any CLR involvement.
>
on my computer, the trial version of mkl is not registered as a shared
dll, so I didnt see a CLSID. The only place in the registry where I
have mkl is the installer and uninstaller. Matlab has it's own local
copy of mkl .
The mkl lib, include, .. directories are added to the windows
environment, but not the bin/dll directory. I think the idea is the
same as with virtualenv, make a local copy, then other programs cannot
overwrite the required version. And there is no need to worry about
shared libraries and no dll hell.
I don't think program libraries for applications need to be installed
system or user wide, for example when I installed Python25 and GTK for
it, GTK installed the new version in Program Files and broke my GTK
install for Python24, or maybe it was GIMP that overwrote the system
wide GTK install. wxpython is installed completely in site-packages,
and I never had any problems with it.
So I think that, if you want to link against mkl, then the best would
be to make a local copy of the dlls. This seems to be the common
policy, for example, I have more than 10 programs (mostly open
source, including numpy/scipy) that all have their own lapack in the
local directories.
Josef