Re: about the gcc 3.4.x problems

In the last episode (Jul 29), Paul Seniura said:
> Scott Long wrote:
> > -Os has never been a supported option for compiling the system on FreeBSD.
> > There is an effort to make -O2 work, but that is also not officially
> > supported yet.  Many of the problems are due to FreeBSD code, of course,
> > but this is a long standing issue and has little bearing on the success
> > of the gcc 3.4 import.
> 
> Okay I am also on record here about the -Os being the DEFAULT SETTING on
> Apple's XCode "deployment" environment.  It _needs_ to be supported.  (I'm
> wondering just how much history y'all have

And that's not a problem.  There there are just X thousand lines of code in
/usr/src that have never been tested with -Os.  That's the only reason that
-Os and -O2 are not "officially" supported.  I have built worlds using -O2
with absolutely no problems for a few years.  That may just be that I'm not
using the programs that have bugs uncovered by -O2 (a libalias bug only seen
under -O2 was recently fixed, I believe).  Build with -Os, and if you find
bugs, send-pr them.

> >> Here, then, is a point I need to make:
> >>
> >> Why is Apple seemingly skipping GCC 3.4.x altogether?
> >
> > So is there a conspiracy against gcc 3.4 that we don't know about?  Do
> > you have information that could help us here?  Or maybe Apple is just
> > being prudent and targeting XCode and GCC releases to somewhat coincide. 
> > That seems to satisfy occums razor a whole lot easier.
> 
> I said "seemingly".
> It makes sense to me.[tm]
> It is something to think about.

I also suspect it's just a timing thing.  Apple is intensly interested in
precompiled headers and other compiler speedups because their system uses a
lots of complex templates.  3.5 is supposed to be the "go-faster" release.

> Have you searched the mail archives here to find out what's
> been said during the past few months?  Again I'm sure some
> of us including myself have mentioned the -fformat-extensions
> problem at several points.  Having most modules linked with
> libstdc(++) in the i386-portbld-freebsd5.2 subdir is not too
> kosher, too.  I mentioned all kinds of things like that. 

In general, C++ object files are not portable across different gcc releases,
since they fix ABI bugs in every release.  Code built with 3.4 may not link
to an old 3.3 libstdc++, thus the dependency on the port's own libstdc++.  I
don't see a problem here.
 
-- 
	Dan Nelson
	dnelson_at_allantgroup.com