Stefan Gybas <gybas@trustsec.de> writes: > * New upstream release (closes: #116644) Good! > * Compile using g++ 3.0 and default optimization (-O2) on i386 Actually, you're compiling with g++-3 on all arches. (FWIW, I'd set CC to gcc-3.0, too, just for good measure.) > If nobody objects I'd like to upload them to incoming in the next few > days, I'll probably recompile the packages on an unstable machine with > g++ 3.0.2 final first. I'll also have to make some small changes for archs > that don't support g++ 3.0 yet, I'll test this on s390. Well, s390 (and all the other arches that jikes needs for testing) /have/ g++ 3.0. I'm not sure whether they really work. Last I checked arm's g++ 3.0 was not able to compile a trivial program. That was some subversions ago, though. The more serious issue, though, is: autobuilders will build jikes against the libstdc++3 version in unstable, and the resulting binary will depend on it. That is it will depend on libstdc++3 (>= 1:3.0.2-1) on mips, libstdc++3 (>= 1:3.0.2-2) on alpha, etc. And testing has 1:3.0.2-0pre010922 currently, so -- guess what -- jikes won't get into testing still. There are two correct options: * build with the default gcc (may not be possible) * build with gcc 3 and be veeery patient while you wait that a suitably high version of libstdc++3 makes it into testing I grew bored with the second option and resorted to cheating: I forced the dependency on libsdtc++3 down via shlibs.local. This is evil insofar as it breaks your program if it relies on functionality introduced between 3.0.2-0pre010922 and 3.0.2-3. I don't recommend this, YMMV, don't try this at home, kids. "Live" picture of libstdc++3 version skew: <URL:http://auric.debian.org/~robbe/madison/libs.html#libstdc++3> I also filed a wishlist bug on libstdc++3 now. -- Robbe
Attachment:
signature.ng
Description: PGP signature