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... 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.
Disagreed.
> 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.
But any of these should not. The entire C Library is very, very
carefully designed to avoid this. Versioned symbols are not fun; they
aren't something that got stuck in for no apparent reason. They're so
that we can maintain compatibility even across much more major version
changes than 2.0.7t -> 2.0.7u ; we have compatibility from 2.0.7 up to
2.0.102 at the moment.
> 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.
But they just aren't.
> 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.
There is one thing I take exception to here - what on earth makes you
think the compiler team is "reluctant" to release snapshots? There are
snapshots made every week and placed on ftp.cygnus.com. There is an
anonymous CVS archive with up-to-the-second updates. They aren't being
somehow forced to release them (which the GPL would not do anyway - if
they do not distribute binaries they are not obligated to distribute
source!)
Dan
Reply to: