[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why not use GCC 3.0?



On Mon, 4 Mar 2002, Jerome Warnier wrote:

> I just finished the (long) installation process of a Woody on an 
> AlphaServer and met a lot of problems during and after the install.

Like what?  Did you file bug reports?

> The problems I had all resolved when using gcc-3.0, using the "apt-get 
> -b source" method.
> That's why I wonder why not use gcc-3.0 on all binary packages for Woody.
> The problems I had resolved by themself when I changed the links to gcc, 
> cpp and g++ in /usr/bin to use the 3.0 version.

There are alot of reasons.  While gcc-3.0 is currently superiour to
gcc-2.95 on alpha, it was not always so.  Also, woody's been in freeze
(for awhile, unfortunately) and changing compilers at this stage would
cause more trouble than it would solve (for instance, all C++ packages
would need to be recompiled).  Because of woody's (hopefully) impending
release, I didn't feel that changing compilers this late in the game was
beneficial to anyone.

> The problems I met:
> - plain kernel 2.2.20, 2.4.17 and 2.4.18 (from kernel.org, and, yes, I 
> needed a more recent kernel because of a Mylex controller in the 
> machine) did not compile, with random compilation errors.

Which drivers?  Most of these can be worked around by removing the
optimisation or reducing it to -O0 for the affected drivers.

> - Netatalk (1.5.1.1-4) appears to have a strange bug on 64-bits 
> architectures, however, recompiling it solved this problem for me (bug 
> #123268).

Most likely another optimiser bug.  There are a few that apparently
generate bad code rather than bombing during compilation.

> Maybe it is even possible to ask for the packaging system to compile 
> with a given gcc version? I'm willing to continue to update my system 
> (apt-get rules!), but I would have to check on each upgrade that it 
> doesn't replace it with a gcc-2.95-compiled version.

Bump/add any epochs in the package versions. That should make it so that
your packages aren't replaced normally by changes in the main archive
(unless the maintainers of the packages do the same, of course).

C



Reply to: