Re: *DO* dynamically link distributed executables
Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes in xemacs-beta(a)xemacs.org:
mb> Maybe Linux didn't do as good a job on the backward
mb> compatibility mechanism for shared libraries as Solaris did?
_Don't_ get us started. ;-)
Too late!
At present, basically it's the problem that the Linux libc was
nowhere
near a vanilla GNU libc until libc.so.6 came out. This upgrade broke
just about every existing binary.
The libc5 -> glibc-2.0 aka libc6 upgrade only broke binaries that used
-rpath -- which suddenly had a hardcoded path to incompatible libraries:
$ emacs-19.34
zsh: 945 segmentation fault (core dumped) emacs-19.34
$
The source changes broke just about everything, but that's a different
issue.
The glibc-2.0 to glibc-2.1 upgrade appears (at this time) to only
break old C++ binaries. This unfortunately means unrecompilable stuff
like the Real Audio player and Star Office 5.0, to name two requires a
careful little dance to get working[1].
For the future, Linux does not have the option of making its own
decisions about the backward compatiblity vs functionality tradeoff.
That's in the hands of GNU.... Which is one reason why the need will
be around for a while.
If we could take the GNU out of "linux-gnu" we would be much better
off. I'm grateful for the software, but the FSF doesn't know diddly
about putting together whole functional systems.
I find it sadly ironic that the hardest part about maintaining a
Do-It-Yourself Linux distribution is overcoming FSF architectural
fuckage.
Footnotes:
[1] You have to have glibc-2.0.7 libraries in a separate directory
and you have to run the ELF interpreter directly. My real audio
wrapper looks like:
#! /bin/sh
LD_LIBRARY_PATH=/home/steve/glibc-2.0.7 LD_PRELOAD=/usr/lib/Real/libnblock.so
/lib/ld-2.0.7.so /usr/bin/rvplayer.LIBC6 $＠
This also contains the run-time workaround for the binary
incompatibility in the Linux 2.2 kernel which changes/"fixes" the
semantics of non-blocking I/O on sound devices.