Re: List of bugs that *must* be fixed before releasing Hamm
> > > > egcc 17768 libc6 bug in mathematical functions [114] (Galen Hazelwood <galenh@micron.net>)
> > >
> > > Fixing this bug exceeds my capabilities. I have send a message to the
> > > egcs-bugs list asking them to look into the current reports, but have
> > > received no responses.
> >
> > Would it be possible to remove "-force-mem" from the list of optimizations
> > done by "-O2"?
>
> I don't know. I'm not an expert on (e)gcc internals.
My problem is that a lot of people use "-O2" for their compiles. If
egcs breaks when doing that then it would be a fairly common occurance.
The question I ask is whether these problems (and the numerous bug reports
that will flow from it) are worth the benefits derived from keeping egcs
in Hamm. My general thinking on this is "no".
Please tell me your opinions on this.
> > > The bug only occurs with optimisation enabled, so it can be worked
> > > around. egcc is the secondary compiler on the architectures for which
> > > hamm will be released (i386 and m68k AFAIK). Personally, I don't think
> > > this bug should delay the release of hamm as 2.0. Brian, please consider
> > > downgrading this to Severity: normal .
> >
> > It wouldn't delay the release... the package would be removed (ala the
> > posting I made last Friday).
>
> That is your priviledge as release manager. However, as a user and a
> developer, I'd like to point out to you that this is a problem of the egcs
> suite as a whole. As our current C++ compiler is the egcs one, you'd have to
> remove it too (or switch back to the 2.7.2.3 one, which is a lot more
> broken). As packages in main must be compilable using packages in main,
> you'd have to remove all packages compiled with it. You would end up with
> something that fits the release criteria, but which would be still-born.
The point about egcs being the primary c++ compiler is a good one. I
hadn't realized that. This makes egcs a much higher priority package (in
my mind, at least) and Debian should ship with a functioning c++ compiler.
That leaves three choices that I see:
- delay Hamm until -force-mem gets fixed
- delay Hamm until -O2 no longer sets -force-mem
- ship Hamm with a bug likely to show up often
Does this seem accurate to you?
I would think (note: I have no experience with gcc code) that doing the
second would not be a tremendous effort, but I'm not sure.
> > > > ftp.debian.org 22390 Please move slink gcc packages to frozen [15] (Guy Maor <ftpmaster@debian.org>)
> > >
> > > This will be obsoleted when 2.7.2.3-4.3 will be accepted into frozen.
> >
> > The changelog says "should fix #22292". Are you not sure it does?
>
> My development station is a laptop with severe disk space constraints. I was
> not in a position to check this. I did the part that required my attention,
> and stuck to the "testing is parallelisable" paradigm.
> I had every reason to assume it does (and it does as Phil confirmed), but I
> did not feel like downloading libc6 in the middle of the night and build it
> (due to the disk constraints, I'd had to have the gcc packages finished and
> their source tree cleaned up before I could attempt building libc6).
> So I didn't test it, which is why it says "should fix".
Okay. I just wanted to clarify since your mail said it "did fix" and the
changelog said it "should fix".
Brian
( bcwhite@verisim.com )
-------------------------------------------------------------------------------
Generated by Signify v1.04. For this and more, visit http://www.verisim.com/
--
To UNSUBSCRIBE, email to debian-qa-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: