On Tue, 19 Aug 2003, Marco van de Voort wrote:
> _the second_ shared lib hell.(=dll hell)
>
> The library system of Linux (*BSD too, I don't know how universal this is)
> is different from that of Windows. One can have multiple versions in
> paralel, at least _IF_ the binary links to the correct library. (and not to
> some symlink),
>
> However, while security wise it might be better to disallow shared libs (not
> dynloaded) in app directories, this kills some flexibility compared to
> Windows too, since Windows allows libraries to be moved/copied to the
> application directory if version conflicts arise.
No, you can do this under Linux too, just use something like:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.
and . (the current working directory AT RUN TIME) will be searched for
shared libraries after the existing library path. If you want the search
order to be the CWD first:
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
Either of those can be put in a wrapper shell script that in turn starts the
binary (StarOffice does/did this).
Easy AND flexible, huh?
> I'd say the overall situation is about the same. Both systems (windows and
> linux) rely too much on properly versioned libraries. A small error takes
> down the entire system. (a minor upgrade that is incompatible etc)
Correct me if I'm wrong, but as the major version number is encoded into a
Linux shared library filename, at least applications can automatically
request to be linked against at least /roughly/ the right version of the
library. Under windows, where most DLLs follow an 8.3 naming convention,
with few encoding the version number into the name (CTL3D, MSVCRT and VBRUN
being the only exceptions, IIRC). As a result clashes are more like to
occur on Windows.
Ultimately though, the decision comes between allowing Windows-style DLL
hell, or Dependency Hell (where each application binary must be linked
against /exactly/ the library it was compiled against). Linux is somewhere
in the middle and still gets moaned at for "Dependency Hell".
> Solution:
> - binaries must _always_ have full version nr of required library.
That would make dependency hell worse, as you'd need /every/ minor library
revision present on your system.
> - I must be able to assign any library version to any binary.
You can do this by mucking with symlinks, or hexediting the binary. But in
my experience, it doesn't work properly anyway, so you're better off just
meeting the requirements of the application you're trying to run, one way or
the other.
> - there must be a system global db which lists version compabilities.
> so if binary lists 2.1.76, the db must list that 2.1.40-2.1.80
> are compatible, and automatically assign the newest version of that
> library available in that range to the binary.
> I'm still in dubio if this should be done only for libraries as a whole,
> or on a per symbol basis ( library version X is compatible with
> library version Y as long as you don't use for symbol Z)
> - There must be a database to register exceptions (specially for proprietary
> software). E.g. if Heroes3 links to old versions libc and gtk, I
> must be able to list that heroes3 (as old binary only game) should
> get assigned some old libc/gtk versions only. (if file=heroes3 then
> assignlibc(x<=libc<=y) and assigngtk(z<=libgtk<=a)
The way it /should/ work is that if the API of a library changes, the major
version number should be incremented. If the API is left the same, then the
major version number can be left unincremented, and old applications can
inherit the improvements.
The problem comes with library authors who don't follow these rules
strictly when changing their library's API. You can have all the technical
solutions in the world, but they're no use if people don't stick to the
rules. ;-]
Best Regards,
Alex.
--
Alex Butcher Brainbench MVP for Internet Security: www.brainbench.com
Bristol, UK Need reliable and secure network systems?
PGP/GnuPG ID:0x271fd950 <http://www.assursys.com/>
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.