Re: binaries compiled on slink don't run anywhere else
I really don't understand how lack of binary compatibility between
distributions can be considered anything close to critical... In my
opinion, it's very, very far from even important. I doubt whether
binary incompatibility with anything but slink has anything whatsoever
to do with the slightest problem.
I am trimming the distribution list because replies to this note and
also the original should probably not go to submit@bugs.debian.org.
I have been around long enough to know 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.
The question becomes: do you want binary compatibility or do you want free
progress to real improvements? I contend that at approximately the level of
the operating system and the base libraries, these two ideas are mutually
exclusive, or nearly so.
If you want something to run on a different operating system, you must
ask yourself: do you have the source code? If the answer is yes, then I'm
sorry, bzzt, wrong, you cannot expect binaries to run there if progress is
desired at the operating system level. Redhat is progressing in their own
direction and so either make decisions about lib and kernel compile-time
options accordingly, or else accept what H. J. Lu creates. My personal
opinion on libs, compilers and kernels, is that any linux user should be
able to get any source code from the definitive source and compile it
themselves.
One thing H. J. Lu does is he tries to help get the libs, compilers
and kernels working together by working on the compiler itself so that it
can compile the kernel and the libs. To do this, he has to use "snapshots"
of gcc and/or egcs (unreleased versions) and send compiler patches to the
team working on the compiler. For this reason, there is a (weak) barrier
whose effect is to try to prevent others from compiling the libs. This also
helps to get a compiler that can eventually compile the libs, but because
the compiler has to be modified to successfully compile the libs, it's
usually behind, there's usually a new lib whose binaries are released but
sources can only be compiled by compiler snapshots, which the compiler
team are usually reluctant to release since it's not stable yet. However
the compiler snapshots are GPLed therefore they can't legally prevent their
release. Somewhat messy... but Mr. Lu is trying his best to provide service
to linux.
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.
In conclusion, I contend that this bug which has been made "critical" is
in no way critical at all. It is not even important, or close to it because
anyone who wants to have a binary on any given system is absolutely free
to compile it there, themselves. Let's find real bugs, please, and get on
with what IS important: the release of 2.1.
-Jim,
who has no vote here and can't keep his mouth shut when important things
come up :)
Reply to: