Re: gcc-3.4 in sarge?
Adam C Powell IV writes:
> Greetings,
>
> I was looking through debian-gcc and debian-java for threads on gcc-3.4
> inclusion in sarge, and came across "gcc-3.4 to [sic] unstable for
> amd64" with a post from jgoerzen:
>
> ---
>
> > 2. will gcc-3.4 be included in sarge?
>
> Highly doubtful.
>
> > 3. is pure64 going to be included in sarge?
>
> No.
>
> > gcc-3.4 will become default after the release, why should we not already
> > build everything with gcc-3.4, since it produces faster code?
>
> I'm not sure that performance is itself a good enough rationale to
> justify breaking from all the other archs in sid.
>
> ---
>
> I agree that it's wise to be conservative with regard to amd64, and we
> certainly don't want to break anything by changing the default compiler.
> And performance is indeed a weak justification for such a major
> infrastructure change.
For amd64 you can find a gcc-3.3 package that builds from the hammer
branch at http://people.debian.org/~doko/gcc-3.3/. That would allow
better amd64 support without relying on gcc-3.4. Should be tested by
the amd64 port maintainers.
> But why not put 3.4 in along with 3.3, the way 3.0 was in woody, such
> that certain packages have the option of using 3.4? Is 3.4 really so
> unstable that it must be excluded from sarge?
It's not my intention to exclude gcc-3.4 from sarge, but to include it
in a way that it doesn't break anything. gcc-3.4 changes ABI's on
mips, mipsel, sparc, hppa, m68k. The only unstable thing in gcc-3.4
itself is the libstdc++ API across Linux distributions (see
http://gcc.gnu.org/ml/libstdc++/2004-06/msg00217.html).
The hppa and m68k changes could be hold back, if gcc-3.4 is still
configured using sjlj-execptions. But that's not what at least the
hppa port maintainers want (and gcj support get's worse).
Some shared libraries now built by gcc-3.3 are replaced by libraries
built by gcc-3.4, but it's partly unknown if they are compatible.
See http://lists.debian.org/debian-mips/2004/06/msg00031.html
> In terms of motivations, my primary one is Java, where including 3.4
> would allow a large number of packages (possibly including my own babel,
> depending on its dependencies) to move to main and run on many more
> architectures.
As soon as package maintainers begin to build packages using gcc-3.4,
it becomes a risk for sarge's stability. The architectures mentioned
above are not the architectures that package maintainers usually build
and test on, so problems may not found before a package moves from
unstable to testing.
gcc-3.4 must not be used for packages containing libraries. I see no
problem building an executable which doesn't depend on a library
(i.e. kernel). Building Java packages using gcj-3.4 (at least on hppa
and m68k) only works, if no other libraries depending on
libstdc++.so.5 are linked in. I didn't check things on mips/mipsel.
My goal is to upload a gcc-3.4 to unstable when it's known wether to
configure --enable-libstdcxx-allocator=pool or =auto, adding a note
reminding package maintainers to be careful mixing gcc-3.3 and gcc-3.4
code.
Matthias
Reply to: