On Thu, 2005-09-15 at 19:47 -0700, Steve Langasek wrote: > On Thu, Sep 15, 2005 at 07:15:16PM -0700, tony mancill wrote: > > Stephen R Marenka wrote: > > > On Fri, Sep 16, 2005 at 10:40:50AM +1000, Anibal Monsalve Salazar wrote: > > > >>>to bug #317475 on gcc-4.0. As a workaround, you might try compiling with > > >>>less optimization or gcc-3.3/gcc-3.4. > > > >>+ifneq (,$(findstring m68k,$(DEB_HOST_ARCH))) > > >>+ CFLAGS = -Wall -O0 > > >>+endif > > > > For the record, -O2 seems to work fine. The segfaults only seem to > > > apply to -O3 and better (at least in my experience). > > > This seems to affect one of the packages I sponsor as well: > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325557 > > > If gcc-4.0 is going to puke on lots of packages that use -O3, doesn't it > > make more sense to upload a patched gcc-4.0 for m68k that silently > > changes the optimization level back to 2 untile the problem with the > > compiler can be fixed rather than upload and recompile a large number of > > packages for every architecture? > > If you have a patch that fixes the ICEs on m68k, by all means please forward > it to the BTS. > > But a larger question is, why are so many packages being built entirely with > -O3 when policy recommends -O2? Policy does say it's ok to use other > compiler flags if appropriate, but I'd be surprised if all of these packages > have been benchmarked to confirm that -O3 actually gives measurable > performance benefits. I don't know if it gives measurable benefits, but all Python extensions use -O3 by default (from /usr/lib/python2.3/config/Makefile). Personally I think it's dumb, but maybe the Python maintainers know better? This is what triggered the bug in python-flac for me. Overriding distutils isn't something I've figured out yet (doing so is a task for the weekend). -- Joe Wreschnig <piman@debian.org>
Attachment:
signature.asc
Description: This is a digitally signed message part