Matthieu Brucher wrote:
> 2009/1/10 Sturla Molden <sturla@molden.no>:
>>>> But LoadLibrary has the same semantics as the windows dynamic loader, so
>>> I am not sure what this would change
>>>>> Sorry I was thinking the other way around: loading multiple DLLs from one
>> binary.
>>>> The cure for DLL hell on Windows is either COM or putting the DLL in a
>> system folder. COM is the preferred solution.
>>>> Microsoft real answer to DLL hell is manifest files (address and
> version of a DLL), but it cannot be applied everywhere
But this is quite complicated to apply in our case. Indeed, in my
understanding, we would have to embed manifest referring to the linked
dll (say atlas). This can only be done reliably (working as non admin on
Vista) if atlas is installed in the SxS cache - using private assemblies
requires the dll to be on the same dir as the .pyd (which means copying
it everywhere we need it....); see this for related problem (with the
msvcrt; the problem is the same, since python 2.6 does not assume you
have th msvcrt9):
http://bugs.python.org/issue4120
As I see it, one solution would be to have a 'private SxS' inside of
numpy - I don't know if it is possible at all. Now, all this is so
hopelessly undocumented that I see little chance to be able to support
this with both mingw and MS compilers (without even talking about Intel
compilers) in finite time. Also, if I can see how we could do it in
theory for atlas, how can we do that for a library we can't distribute
and control ourselves like MKL ?
MS could have used something like rpath + $ORIGIN which exists for like,
ten years at least, but no, they had to use all those crappy XML files
embedded in binaries with obscure semantics documented nowhere... Why
should I waste my time for such a crappy platform ? If people are really
interested in that feature for windows, they should do it themselves - I
won't do it.
cheers,
David