[Interest] Qt5, XCB and X11

[Andreas Pakulat]

Hi,

On Fri, Jul 11, 2014 at 2:47 PM, Till Oliver Knoll <
till.oliver.knoll at gmail.com> wrote:

> But other systems such as Linux also share some affinity to the "DLL
> Hell": agreed, most developers there have learned from the very beginning
> that it is probably not a good idea to install their own libraries under
> /usr/lib – but dare you try to deploy your app on different Linux
> distributions! Off course the Unix/Linux folks also tried to overcome the
> "DLL Hell" by encoding "version info" into their libs, such as
> libfoo.0.4.2.so – but most apps simply don’t care about linking with
> –lfoo.0.4 (or whatever the syntax would be), so they’d also happily link
> with a libfoo.0.5.0.so, which in the best case might be binary
> compatible, but otherwise behave differently and *bang*! There you go:
> "Shared Objects Hell"!
>

While I agree that you can end up in the same dll-hell on Linux or other
ELF based systems, this paragraph is largely wrong. First of all, during
linking you either specify the absolute path of the library you want to
link to or you just specify the name (the foo part in libfoo.so). The other
thing is that the library version information is encoded into the .so file
as well as appended to the filename, but not in the way you suggest. The
SOVERSION is a single number intended to indicate binary incompatibility
between two versions of a library and the filename corresponding to this is
libfoo.so.<num>. All other libfoo.so.* are just aliases for convenience and
clarification. This single-number filename is also whats stored in the
application executables or shared libraries linking to libfoo. The dynamic
linker will use that one for resolving the symbols and only that one. If
there is a libfoo.so.2 and a libfoo.so.1 an application that was compiled
and linked against libfoo.so.1 will never get  libfoo.so.2 loaded by the
dynamic linker (unless it also links against another library that happens
to use libfoo.so.2 and then you're in hell indeed).

Often the SOVERSION matches the major version number of the project, but
this does not have to be this way. For example KDE's core library
libkdecore on my system is libkdecore.so.5, with a symlink
libkdecore.so.5.11.5. The projects version is however 4.11.5.


> I think the problem on Linux is less of an issue simply because you have
> no other choice than "building and testing on the exact same distro where
> you also intend to deploy" – or you provide the "do it yourself"-sources in
> the first place. Or let the distro owner compile and distribute the
> binaries for you. Or go a long mile, restrict yourself to the lowest common
> denominator of all the distros that you plan to support, test on a massive
> array of hardware/distros/versions and try to deploy your binary there
> (such as Qt does).
>

Actually its not that much of a long mile. If you pick a sufficiently old
linux distro to compile on then chances are you can support really old
distro's and a wide variety too. At work we build most linux packages on a
debian lenny (2012) and a debian etch (2010) machine, this is sufficient
for I'd say 95% of our linux customers that use our binary packages. For
the remaining 5% we still have a Sarge (2005) linux machine that can build
a subset of our packages.

It also depends on what you are willing to ship yourself, i.e. if can you
assemble a bundle that only relies on libc6, libstdc++ and maybe libX11
(for UI apps) then you can target a much bigger range of distributions
since libc, libstdc++ and libX11 have really solid binary compatibility. If
you want to ship less stuff yourself you indeed end up being more limited
in which distributions will be able to run your binary bundle.

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140711/3de38d00/attachment.html>