On Sat, 31 Oct 2009 23:58:33 +1300, Lawrence D'Oliveiro wrote: > In message <mailman.2365.1256979069.2807.python-l...@python.org>, Albert > Hopkins wrote: > >> On Sat, 2009-10-31 at 21:32 +1300, Lawrence D'Oliveiro wrote: >> >>In message >><6e603d9c-2be0-449c-9c3c-bab49e09e...@13g2000prl.googlegroups.com>, Carl >>Banks wrote: >> >>> Modules will sometimes find themselves on the path in Windows, so the >>> fact that Windows performs a library search on the path is quite >>> significant. >>> >>> Why is it only Windows is prone to this problem?
I question your assumption. "DLL hell" is merely a platform-specific name for a particular variety of a broader class of problems, namely dependency conflicts and the bootstrapping problem. It's not even specific to software -- bootstrapping problems are well known in many fields of endeavour: before you can make the tools to make things, you need to make the tools to make the tools... It is far from true to say that Windows is the only system subject to this problem. http://en.wikipedia.org/wiki/Dependency_hell Python, like most (all?) programming languages, has it's own version of dependency hell, namely circular imports: module A depends on module B, which depends on module C, which depends on module A... Python also has a second "DLL Hell", as many newbies discover: shadowing standard library modules. Create a module (say) "random.py" in the current directory, and then try to import the standard library random. This is a form of DLL Hell, because Python uses standard library modules dynamically, importing them at runtime. One solution to dependency conflicts and circular dependencies is to avoid dependencies altogether. At the cost of disk space and memory, use static linking and give up the benefits of dynamic libraries. Platforms that encourage static linking avoid the DLL conflicts, but at the cost of increased memory and storage usage, and static applications need to be upgraded individually instead of merely upgrading the shared library. >> I think as someone pointed out earlier, in Unix-like operating systems, >> a "regular" library's file name starts with "lib", e.g. libcrypt.so. >> So this would not conflict with Python's crypt.so. But it would conflict with a Python module libcrypt.so if the PYTHONPATH and the OS's shared library path coincided. > I just checked my Debian installation: > > l...@theon:~> find /lib /usr/lib -name \*.so -a -not -name lib\* > -print | wc -l 2950 > l...@theon:~> find /lib /usr/lib -name \*.so -print | wc -l 4708 > > So 63% of the shareable libraries on my system have names NOT beginning > with lib. 53% on my system. This just goes to show that even Linux developers often don't bother with the conventions for their platforms. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
