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