On Sat, 30 Sep 2000, Marc Lehmann wrote:
> Which still makes it an broken, experimental, unreleased and unofficial
> compiler, with all the consequences I said.
I agree about the "unreleased and unofficial" part, but it's not quite
that broken and experimental. Everything that is shipped with Red Hat
Linux (the distribution itself, Powertools, the extra CDs for Europe,
etc) compiles and works without problems.
Some programs needed patches, but that was much like updating from egcs
1.1.2 to gcc 2.95 - stricter checks for clean code.
> > possible, but 2.95 isnt binary compatible with anything past or future and
>
> Not true,
Why not? Its C++ part definitely isn't binary compatible with the previous
(egcs 1.1.2) version and the future (gcc 2.96) version.
The C part is, and so is the C part of the 2.96 compiler in Red Hat Linux
7. (We're still fully LSB compliant.)
Also, it's GPL code, so anyone who wants to use it on other distributions
can just take libstdc++; people providing binary-only software can include
whatever version of libstdc++ they used with the binary and LD_PRELOAD it,
or even link it statically.
This is much like saying everyone who ships gcc 2.95.x is just trying to
make everybody not use Red Hat Linux because we never shipped it, and
therefore aren't shipping the libstdc++ used by 2.95.x.
> but even if it were, 2.95 is compatible to all other distributions
At the moment, yes. Once the next gcc is released, they'll start updating,
and 2.95 would be incompatible.
We don't break binary compatibility in minor releases (which is why even
6.2 still used egcs 1.1.2 even though gcc 2.95 was better), so we'll stick
with a similar compiler throughout the 7.x series. Keeping 2.95 all the
time wouldn't do much to increase binary compatibility when everyone else
starts updating.
> And the next gcc release will be worse, so where is the logic behind
> choosing a compiler not compatibly to ANYTHING, except if trying to force
> customers to stick to redhat?
It was a purely technical decision, made by the compiler engineers at
Cygnus and our development.
We wanted ia64 support (using 2 different compilers for the 7.0 release,
just on different architectures, wouldn't be nice), the new ia32 backend,
as well as the more complete C++ implementation and ISO C99 compliance.
We don't want to stick with 2.95 for the next year or two, so this was the
only way to go.
> gcc-2.96 (remember that this thing is not precisely defined as no such
> release exists) produces worse code,
So the new ia32 backend isn't better than the old one? Why? And if the old
one was so much better, why was it replaced?
> It would be better than a world where I cannot switch to another
> distribution because vendors only support redhat and the binaries will not
> run on the "competitors" linux' distros, forcing me to use redhat binutils,
> redhat gcc, redhat libc and so on.
Either link statically to libstdc++ (c++ is the only part of the
compiler which is not fully ABI compatible), or just install the
libstdc++-3-libc6.2-2-2.10.0.so file from Red Hat Linux, possibly even to
a different directory with LD_PRELOAD or the likes set. This won't break
anything.
> Well, if redhat really tried to do this they failed miserably. OTOH, maybe
> the redhat people doing that were drugged, because every child could
> deduce that using an experimental snapshot that is has a non-fixed and
> changing ABI will not help binary compatibility.
When the decision was made (and I still think it was the right decision -
especially because of ia64 compatibility), there was still some hope that
gcc 2.96 would be ready by release time.
If it's of any help, I can put up all potentially incompatible libraries
as a plain tarfile somewhere, along with detailed instructions on how to
use them for compatibility on other systems. Breaking compatibility has
never been one of our intentions.
LLaP
bero
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:27 EST