Anthony Towns writes: > On Tue, Apr 15, 2003 at 08:45:46AM +0200, Matthias Klose wrote: > > # -gcc (2.95.2-20 to -) > > * Maintainer: Debian GCC maintainers > > * Boss says I shouldn't remove gcc > > * Not considered > > This is still in update_excuses, although the package is removed in > > unstable. > > Yes, the exception is hardcoded: > > if src == "gcc": > exc.addhtml("Boss says I shouldn't remove %s" % (src)) > okay = 0 > > It's providing libg++2.8.1.3 and libstdc++2.10; libg++2.8.1.3-glibc2.2 > and libstdc++2.10-glibc2.2 is what everything in Debian uses now; those > two libs are only useful for compatability with (reasonably old) third > party C++ stuff. > > This shouldn't affect gcc maintentance *at all*, unless you want a gcc > source package (instead of gcc-defaults/gcc-X.Y), or want to provide > those libs.
There should be no third party packages depending on libg++2.8.1.3. What is wrong with installing libstdc++2.10 from an older debian release? OTOH there is no reason to remove it. > ] stage1/xgcc -Bstage1/ -B/usr/m68k-linux/bin/ -DIN_GCC -O2 -W -Wall > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional > -pedantic -Wno-long-long -DHAVE_CONFIG_H -I. -I. -I../../src/gcc > -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include -c > insn-recog.c \ > ] -o insn-recog.o > ] insn-recog.c: In function `recog_7': > ] insn-recog.c:9893: internal error: Illegal instruction > ] Please submit a full bug report, > ] with preprocessed source if appropriate. > > - Sun 13 Apr 2003 20:10: maybe-failed > > http://buildd.debian.org/fetch.php?&pkg=gcc-3.2&ver=1%3A3.2.3ds7-0pre8&arch=m68k&stamp=1050279027&file=log&as=raw This one I see the first time. I'm reverting the two m68k patches applied in the last upload for now. > Do you guys know what you're doing about gcc 3.2 v gcc 3.3, or is > everything still all confused about it? > > I don't really know gcc well enough to comment, but if it's what you > need and want, I'm happy to say "focus on 3.3 for sarge", and work > from there. Whatever happens, we do need to have a working toolchain > for all architectures in testing and unstable (and stable of course) > as continually as possible; if 3.3 is the best way of achieving that, > that's great. That's what IMO is the goal to strive for. The last gcc-snapshot compiled fine on all architectures, so I uploaded 3.3 enabled for all architectures. So my plan is: - Wait until fixed 3.2 and 3.3 packages are in testing. - Let the port maintainers decide, if they want 3.3 as the default compiler (gpc will be the default on ia64 and hppa, but this is not so important). - Make 3.3 the default once it is released on all architectures, unless the port maintainer wants to keep 3.2 as the default. Matthias