Alexey,
> what exactly do you propose from technical side:
> create 3 gcc-csl branches and test ON on 4 compilers ?
no: I'd propose the following:
* Identify the changes currently local to the csl-sol210-3_4-branch branch
(which is the basis for the gcc 3.4.3 in sfw) necessary to build
OpenSolaris and missing in GCC mainline/4.1 branch.
* Try to get as many of those changes as possible into gcc mainline, either
for 4.2 or for 4.3 after 4.2 branches.
* Create two solaris vendor branches (this isn't a csl-only thing, but
should be backed by the opensolaris community as a whole): one off gcc
4.1 and another off gcc mainline.
* Apply the necessary changes there.
* Use the 4.1-based branch as the basis for a gcc 4.1 in sfw.
* Start testing with the 4.1-based branch regularly (and perhaps switch the
sfw gcc from 3.4 to 4.1 if this works out).
* Continue testing with the 4.2/mainline based gcc to make sure it at least
compiles ON to be able to switch when/if it is released/stable enough.
> I think it would unwise to try to support development branch which is 4.2
> in ON. Do you see that Linux adopts it ?
You need to distinguish two thinks:
* Building production Linux (or OpenSolaris) kernels with a gcc 4.2 based
compiler. This is clearly unwise.
* (Regularly) testing with such a compiler.
The former certainly does not happen, the latter does, as you can see from
regular bug reports about issues detected when building and running Linux
with gcc mainline.
> The most recent shipped Ubuntu kernel for sparc 2.6.15 is built
> with gcc 4.0.3-1
This may be due to what was current at the time they started the
corresponding release cycle. Switching compilers late in the cycle is
certainly a bad idea, but the result of the current OpenSolaris-with-GCC work
should effectively target the Solaris 11 release, so baseing something on
GCC 4.0 for that release is a bad idea since that compiler will be
completely obsolete/unmaintained at that time.
> One thing is to make ON buildable with gcc 4.1 or 4.2, but to support
> it is a bit different.
True, but this doesn't happen now either: the current O/N build procedure
only makes sure that it compiles with the sfw GCC 3.4.3, nothing more. I
think you will find much more support in the GCC community to fix bugs in
4.1/mainline than on the almost abandoned 4.0 branch.
> > While this does not apply to the ON changes necessary to build with GCC
> > (either GCCfss or GCC 4), it applies to the GCC changes necessary to do so.
>
> That's orthogonal discussion. It's certainly would be great to have
> GCC developers test their new features on ON.
I think you misunderstood: what I tried to say was: we need to feed back
most (if not all) OpenSolaris-specific GCC changes back into GCC mainline
(or a vendor branch if they are somehow unacceptable for FSF GCC).
Testing GCC on ON/Nevada is something the OpenSolaris community needs to
do: this is part of being a member of the GCC community. We cannot expect
others to do this for us.
> > On the other hand, I'd strongly argue against basing any development on GCC
> > 4.0.x right now: there will most likely be no further release from that
> > branch, so I'd suggest to concentrate on the latest stable GCC release
> > (4.1.1 right now) or even on making sure everything still works with the
> > upcoming GCC 4.2.0 instead. Basing considerable amounts of work on an
> > obsolete version is a loosing proposition IMO.
>
> No SC sponsored releases doesn't mean that there will be no further releases
> from 4.0 branch. It seems Linux doesn't see the extra value of gcc 4.1
If there's no 4.0 branch maintainer, who would do the work on the 4.0
branch. I don't see CodeSourcery being very active with GCC for Solaris
work these days (maybe their contract has ended?), only Roger Sayle
recently started a considerable amount of work on GCC mainline for
Solaris/x86 (which is very good since that platform has been quite
neglected as a GCC platform).
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
