Re: binaries compiled on slink don't run anywhere else
On Sun, Nov 15, 1998 at 02:42:04AM -0800, jim@laney.edu wrote:
> I really don't understand how lack of binary compatibility between
> distributions can be considered anything close to critical...
You can't use Slink to provide precompiled binaries for simple
programs and expect them to run on RH systems. Source code
availability solves nothing on some situations. For example, there
are some RH machines here that *don't* have a compiler installed at
all (or don't have every -dev(vel) package installed, or a C++
compiler) I compile programs on the Debian boxes and I'd expect the
binaries to run on RH (mind some stupid soname incompatibilities)
Isn't that critical? (Put in another way, what would happen if
precompiled Mozilla packages are distributed and NS happens to be
running Slink?)
> I have been around long enough to know
ok...
> that two compiles of the same library with only one or two option
> changes can mean binary incompatibility. Header files change, and
> so do kernel versions as well as compilers. Any one of these can
> result in total incompatibility between binaries. Because debian
> has chosen to take on the maintainance of the compilers and libs
> and to make most or all of the decisions about their compiling, the
> only route to full binary compatibility is to copy what the other
> dist does, i.e., to have the exact same kernel options when
> compiling the kernel, then the exact same library config when
> compiling the library, the same header files and etc.
Not agreed. There *are* some imcompatibilities between Debian and RH
(the JPEG library for example) but there are some libraries that
*should not* be imcompatible (the C library!) If you give me some
technical reason as to why binary compatibility at the C library
level should be broken, I'll shut up.
> Hence, binary compatibility is very difficult to achieve, and
> probably not worth the effort if the goal is to progress at the
> systemic level. I therefore contend that source code compatibility,
> being the mainstay of open-source, is quite sufficient. If one has
> the source, one can compile it themselves and should -definitely-
> do so, or risk subtle breakages or full incompatibility.
I wouldn't even think about running this on a RH system:
$ ldd /usr/X11R6/bin/moonlight
libz.so.1 => /usr/lib/libz.so.1 (0x40011000)
libjpeg.so.6a => /usr/lib/libjpeg.so.6a (0x40020000)
libtiff.so.3 => /usr/lib/libtiff.so.3 (0x4003e000)
libgltt.so.1 => /usr/lib/libgltt.so.1 (0x40074000)
libttf.so.1 => /usr/lib/libttf.so.1 (0x4007f000)
libMesaGL.so.2 => /usr/X11R6/lib/libMesaGL.so.2 (0x40097000)
libMesaGLU.so.2 => /usr/X11R6/lib/libMesaGLU.so.2 (0x401ad000)
libpthread.so.0 => /lib/libpthread.so.0 (0x401cb000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401d9000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401e5000)
libm.so.6 => /lib/libm.so.6 (0x40289000)
libc.so.6 => /lib/libc.so.6 (0x402a1000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libglut.so.3 => /usr/lib/libglut.so.3 (0x40342000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40372000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40384000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x403cd000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x403d5000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x403de000)
libg++.so.2.7.2 => /usr/lib/libg++-dbg/libg++.so.2.7.2 (0x403f3000)
libstdc++.so.2.7.2 => /usr/lib/libg++-dbg/libstdc++.so.2.7.2 (0x4042b000)
but I'd expect a lousy binary linked agaist two very basic libraries
(that happen to come from the same source) to run on a another system
that claims to have the same version of those libraries... or is the C
library *that* customizable at compile-time?
> -Jim,
> who has no vote here and can't keep his mouth shut when important things
> come up :)
I'd think you do have a "vote" if you can provide enough arguments to
support it. If, a priory, you don't have a vote, then neither does
Alan Cox... and I guess he does have one.
Marcelo
Reply to: