On Sun, Jun 08, 2003 at 09:20:47PM -0700, Ross Boylan wrote: > On Wed, Jun 04, 2003 at 11:24:40PM -0400, Joey Hess wrote: > > Yes, they were very carefully compiled with good old 2.95, until mid-may > > week, when they finally switched over to using 3.2. > > That raises a couple of more general issues. > > I thought the default compiler for the next release was 3.2. Will it > in fact be 3.3? My testing system has moved to 3.3 with recent > updates (actually very soon after it went to 3.2).
Yes, it'll be 3.3. > Are 3.3 and 3.2 binary compatible, particularly for C++? I know 3.2 > was incompatible with previous versions for C++. I've looked at the > gcc website, but I can't tell from there. I think they're more or less binary compatible; I've heard rumours of one or two wrinkles in the C++ ABI but don't know the details. > Finally, Colin Watson wrote in some previous threads that the > avoidance of update-alternatives for gcc was deliberate. Could he, or > someone else, say a bit more about why? I don't see why setting gcc > (and friend, I assume) up as a symlink is any different from using > alternatives (which is just two symlinks). Well, I'm not a toolchain guru by any means, but: It's because some of the heaviest and pickiest users of gcc on Debian are the developers and build daemons themselves. It's important for those use cases to be able to guarantee some degree of consistency just by installing the current versions of gcc-defaults packages, particularly in cases like C++ where nasty ABI compatibility problems are involved, but also for example when code generation bugs are discovered on certain architectures. The build daemon administrators and individual developers working on those architectures aren't necessarily experts in all the issues affecting the toolchain; the people uploading the compiler are. Alternatives are notoriously flaky anyway; there are all kinds of complicated bugs open surrounding manual and auto mode and the times when it decides to use one or the other. There was great amusement in unstable a couple of years ago when perl was trying to use update-alternatives for different versions of itself, it broke, and suddenly you could no longer use update-alternatives to put it right because that program is written in Perl. In this case where consistency and the idea of a single clean and consistent compiler installation are important, I'm just as happy that we don't use them. Users can still do everything they want with diversions, and I think dpkg-divert is an underused tool anyway. > And does the gcc toolchain know how to call the right version of > related tools once you start it (e.g., linker, assembler)? The linker and assembler are part of binutils and so are on a different version scheme, but gcc does know how to call the right version of subprograms like cc1, yes. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]