Binary incompatibility of Linux distributions

[Steven Susbauer]

On Thu, 21 May 2009 17:58:39 -0500, Jerry Houston <jerry at effjayare.net>  
wrote:

> On Thursday 21 May 2009 06:13:25 am Derek Broughton wrote:
> Total BS.  I build MSI installers frequently (I created two new ones at  
> work
> today), and they include any dependencies that are required.  It's part  
> of the
> architecture.
>
> On the other hand, I have yet to get RealVNC installed on my Ubuntu  
> machines
> here at home, because although I can un-gzip a binary package to my  
> machine, I
> can't provide the c6-something-so3.something "common library" that it
> requires.  If it were a required DLL for a Windows system, it would be
> included in the MSI.
>
> Like I said, I'm a Linux enthusiast.  But I'm also a Windows  
> professional, and
> have been for more than 20 years.  I call BS when I see it.
>

You're comparing .msi, which is comparible to a package, to a randomly  
built binary that is essentially zipped (and I will tell you from  
experience, random zipped binaries don't always work on Windows either).  
If you were operating from a .deb, there is an extremely high chance that  
the required library would be installed automatically (but not included in  
the package itself, thank God!). Try installing backintime, which is not  
in Jaunty, from a (developer provided) .deb and you will find it pulls in  
the required libraries as expected.

RealVNC (free) will not run on your Ubuntu machine because you are  
downloading the binary which was built to use libstdc++6-2.2, Ubuntu has  
libstdc++6-4.3. This is exactly the type of system library I would never  
*want* a random application to be modifying. This is not uncommon when  
trying to run old binaries thar are randomly downloaded from a website,  
and is likely to occur (in this case) trying to run on any modern distro  
with an updated libstdc++. Downloading the source file and compiling it  
would generally result in functional binaries, but does not because their  
source is also in need of updating (this is probably why distros dropped  
it). I would suggest working with a supported, or at least actively  
developed, application.

Windows installers flinging libraries all over the place is not a plus. It  
is well known that Windows becomes bogged down if you install and remove a  
lot of programs (and those programs generally leave a lot of cruft), also  
not all programs are kind with their placement or replacement of DLLs and  
can overwrite those used by other applications. I much prefer the  
decentralized approach. Applications made for the distro will pull in the  
required libraries. Generally using broken methods results in  
nonfunctional applications.