Re: update-alternatives and gcc
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 [cjwatson@flatline.org.uk]
Reply to: