Re: A Linux Newbie's Main Issue With Linux

On Tue, 19 Aug 2003, Bill Wisse wrote:

> Back to Linux (rpm) and dependencies.
> When I buy my SuSE cdrom's ( with RPM's) there is NOT one dependency problem!
> If it can work for all those programs together, why can't it work for one 
> single program?
> Or am I shortsighted?

All the programs supplied in a given distro are compiled against the
libraries supplied with that distro and are thus internally-consistent.

If you start trying to install and run binaries compiled on other systems
(which have different library versions installed) then they will require the
libraries they were compiled and dynamically linked against to be installed
on any system they are to be executed on.

The solution is to stick to binaries that are compiled for the version of
the distro you're running, preferably in that distro's native package format
(e.g. RPM, dpkg) so that the package database is consistent with what's
actually installed on the system.

If the package you require isn't available for the version of the distro
you're running, the best bet is usually to build it from source. I recommend
using an existing package definition (i.e. src.rpm or whatever) as a
template for building a new native package for database consistency reasons
detailed above and also to aid removal/upgrading/regression at a later date.

Windows application authors also experience the same root problem, but get
around it using a combination of:

a) Static linking, leading to large executables and bugs/security problems
requiring multiple applications to be upgraded.

b) Allowing applications to upgrade (and sometimes even *downgrade*!) system
libraries when they are installed. This may break other applications which
require specific versions. In Microsoft's defence, I don't think they've
ever recommended that application installers do this, and they are working
hard to stamp out the practice (witness the windows\sysbckup\ directory,
Windows File Protection and similar). This is the most common cause of
Windows "DLL Hell".

c) Shipping applications with the versions of the libraries (DLLs) they were
linked against and installing them in an application-specific directory. I'm
not a Windows programmer, but if I remember correctly how it works, with
Windows crazy global symbol resolution scheme, this means that the order in
which applications are loaded affects their behaviour. Imagine this
scenario:

- Application A ships with LIBFOO.DLL, version 1.0, which has a bug in at
least one of the functions it provides.

- Application B ships with LIBFOO.DLL, version 1.1, which fixes at least one
bug in the functions provided by v1.0.

- Application A works around a bug in LIBFOO.DLL v1.0 and was written and
compiled before v1.1 was available.

- Application B requires LIBFOO.DLL v1.1 because it fixes a bug that was
present in v1.0. It does not contain a workaround for the bug, as the
application ships with v1.1.

- If Application A is started first, LIBFOO.DLL v1.0 will be loaded into
memory and it will run as expected. If Application B is then started, it
will link against LIBFOO.DLL v1.0 and fail as some point when it .

- If Application B is started first, LIBFOO.DLL v1.1 will be loaded into
memory. If Application A is then started, it will link against v1.1 and may
fail at some point when it tries to workaround a bug that is no longer
present.

Linux, at least, has a per-process symbol table, so this sort of craziness
doesn't happen if libraries are shipped with binaries and
LD_LIBRARY_PATH/LD_PRELOAD environment variables set accordingly (StarOffice
did/does this to maximise the number of distros it runs on). But memory
and disc requirements are still excessive compared with multiple
applications linking against the same versions of the libraries they
require.

The true Free/Open Source approach to the problem described above would be
for the authors of Application A to report the bug in libfoo to libfoo's
authors (optionally supplying a patch to fix it themselves), then waiting
for v1.1 to become available and using that when creating their application.
Also, if the change in behviour is significant, libfoo's version number
should really be incremented to v2.0 so that it may co-exist on systems with
v1.0 and applications that rely upon the old (broken) behaviour can still
link against v1.0.

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/>