about the gcc 3.4.x problems
Dan Nelson
dnelson at allantgroup.com
Thu Jul 29 10:44:22 PDT 2004
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
More information about the freebsd-current
mailing list