GNU Developer Collection [LSARC/2008/776 FastTrack timeout 01/07/2009]
Rainer Orth
ro at techfak.uni-bielefeld.de
Wed Jan 7 11:43:54 PST 2009
George Vasick writes:
> >> 2. Project Summary
> >> 2.1. Project Description:
> >> The project will provide the current releases of the GNU Compiler
> >> Collection (GCC) and the GNU Binutils for OpenSolaris. The primary
> >> components are the following:
> >> - GCC includes C, C++, FORTRAN, Objective-C, and Objective-C++.
> >
> > Why exclude GCJ (i.e. the Java compiler) and GNAT (Ada compiler)?
>
> We based the included languages on what was done for the current
> opensolaris version of gcc, 3.4.3. We will definitely consider
> including additional languages in the future if there is demand.
I don't really think there's reason to delay this to a later date. GCJ
works out of the box on both SPARC and x86, as does GNAT (and I can provide
bootstrap compilers if desired). I regularly test the whole suite with
relatively good success. True, adding Ada support will require a flag day
for build machines since building GNAT requires an existing Ada compiler,
but this can be handled, I think. On the other hand, omitting them forces
users to build GCC on their own, which gets increasingly hard these days
due to growing list of dependencies, and is especially hard for Ada where
you need to get hold of a bootstrap compiler somehow.
> >> 4. Technical Description:
> >> 4.1. Details:
> >> - Existing GCC 3.4.3, GNU Runtime 3.4.3, and GNU Binutils 2.15 will
> >> remain unchanged in /usr/sfw/.
> >> - The latest community versions, GCC 4.3.2, GNU Runtime 4.3.2, and
> >> GNU Binutils 2.19, will be ported to OpenSolaris and installed in /usr/compilers/gcc432.
> >
> > This doesn't seem appropriate: as I've established during the (currently
> > derailed) PSARC 2008/656 case, GNU as 2.15 and 2.19 are completely
> > compatible and 2.19 can be used as a drop-in replacement for 2.15, even
> > with GCC 3.4.3. What's the relation of this case to PSARC 2008/656, anyway?
>
> Ideally, we would end of life GCC 3.4.3 and binutils 2.15 currently
> installed in /use/sfw. We need to do it in multiple steps, make GCC
> 4.32. and binutils 2.19 available, allow existing Solaris consolidations
> which depend on 3.4.3 to migrate to 4.3.2, and finally end of life 3.4.3
Understood, allowing O/N to build (and work) with GCC 4 is certainly a
major effort.
> In the interim, we would like to leave the existing GCC 3.4.3 and
> binutils 2.15 completely untouched.
I'd object to this: GCC and binutils release schedules are in no way
related, and there is no reason why GCC 3.4.3 cannot work with gas 2.19.
In fact, I've performed an experiment when the PSARC/2008/656 (binutils
2.17) case was on the plate, which I reported in private mail since the
case had been already derailed: my claim stands that binutils 2.19 are a
drop-in replacement for 2.15 and there's no reason to have compiler-version
specific binutils at all. They belong in /usr/gnu/bin resp. /usr/bin
without additional versioning:
To add some facts to this discussion, I've performed the following
experiment:
* First of all, I built gcc 3.4.3 from sfw-src-b101a-20081022.tar.bz2 and
ran the whole testsuite for both 32 and 64 bit.
* Then I dropped gas 2.19 into /usr/sfw/bin/gas and reran the gcc testsuite
without rebuilding gcc. There were no regressions.
* Then I rebuilt gcc 3.4.3 with gas 2.19 (as /usr/sfw/bin/gas) and rerun
the testsuite again. Again, there were no regressions and gcc didn't
pick up any new features from the newer gas (as verified by comparing
gcc/auto-host.h files which contain the results of the autoconf tests).
I just had to backport a trivial patch from gcc mainline to handle the
incompatible output format of gas --version:
*** gcc-3.4.3/gcc/configure.orig Tue Nov 9 02:49:32 2004
--- gcc-3.4.3/gcc/configure Thu Oct 30 14:03:08 2008
***************
*** 10539,10545 ****
# arbitrary sections are supported and try the test.
as_ver=`$gcc_cv_as --version 2>/dev/null | sed 1q`
if echo "$as_ver" | grep GNU > /dev/null; then
! as_ver=`echo $as_ver | sed -e 's/GNU assembler \([0-9.][0-9.]*\).*/\1/'`
as_major=`echo $as_ver | sed 's/\..*//'`
as_minor=`echo $as_ver | sed 's/[^.]*\.\([0-9]*\).*/\1/'`
if test $as_major -eq 2 && test $as_minor -lt 11
--- 10539,10546 ----
# arbitrary sections are supported and try the test.
as_ver=`$gcc_cv_as --version 2>/dev/null | sed 1q`
if echo "$as_ver" | grep GNU > /dev/null; then
! as_ver=`echo $as_ver | sed -n \
! -e 's,^.*[ ]\([0-9][0-9]*\.[0-9][0-9]*.*\)$,\1,p'`
as_major=`echo $as_ver | sed 's/\..*//'`
as_minor=`echo $as_ver | sed 's/[^.]*\.\([0-9]*\).*/\1/'`
if test $as_major -eq 2 && test $as_minor -lt 11
I suppose this should strongly support the claim that gas is upwards
compatible and there's no reason whatsoever to have compiler-specific
installations of binutils.
> I contacted Stefan Teleman, the submitter PSARC 2008/656. Binutils 2.17
> has not yet been integrated and he agrees that we should go directly to
> 2.19 at this point.
True, this will certainly benefit a future integration of GCC 4.4 which can
make use of some binutils 2.19 features.
Otherwise, if you keep binutils 2.19 in /usr/compilers/gcc4.3.2 and add GCC
4.4 later, will the 4.4 compilers refer to gcc4.3.2 gas, or add their own
private copy? This makes no sense to me. I even think that the binutils 2.19
and gcc 4.3 cases need to be separated.
> > Apart from that, I see no reason to make this micro-version dependant: the
> > libraries remain ABI compatible inside a minor release.
>
> We see only one reason. That is to minimize effort on 3.4.3 and move to
> end of life it instead.
I don't think this claim holds: the GCC team has pretty strict rules about
integrating regression bugfixes into micro releases. I'd claim having the
micro-version specific directories is bad: this isn't done for other
components like apache2, postgres or mysql. In case a newer micro release
of GCC should be added in the future, users have to change their PATHs to
match the change, which is unnecessary and inconvenient. Even worse,
depending on how the GCC shared libraries are linked, you would have to
keep different micro release directories in parallel so the libs can still
be found. Overall, this seems like a unnecessary mess to me.
> >> 4.5. Interfaces:
> >>
> >> The following interfaces are classified volatile since they are controlled by GNU:
> >
> > This isn't enough of a justification (and makes the compilers useless).
>
> We will not make any incompatible changes, however they are controlled
> by any outside body. I reviewed ARC's interface taxonomy document
> again. It seems to me these interfaces fall somewhere between
> uncommitted and committed depending on how well GUN controls them. What
> do you propose here?
I'd have to review the interfaces in detail. If we want to make some
overall classification for everything, Uncommitted seems about right, but
there are parts that do better (like libgcc_s.so.1, which could probably
become Committed). Some of this might be improved if one would add Solaris
support for interface versioning to more libraries: libgcc_s.so.1 currently
has it, while e.g. libgomp.so and libstdc++.so use GNU ld specific features
and we'd have to work out how to achive this with Sun ld.
> > Btw., what's the reason to deliver libtool .la files? They often seem to
> > cause more trouble than they are worth.
>
> We provided .la files with the 3.4.3 version of GCC. If they are not
> useful, we can consider deleting them.
I think they caused more trouble than they are worth. Perhaps you could
review Bugster for .la relates bug reports?
> > * There are some static libraries listed above:
> >
> > /usr/compilers/gcc432/lib/libiberty.a
> > /usr/compilers/gcc432/lib/libssp_nonshared.a
> > /usr/compilers/gcc432/lib/libsupc++.a
> >
> > Should the be delivered at all, especially in /usr/lib?
>
> We also agree.
On second thought, we may need to investigate if/when libsupc++.a is used.
Maybe this has to be kept?
> >> 4.10. Packaging & Delivery:
> >> Name Stability Notes
> >> ==== ========= =====
> >> SUNWgcc432 uncommitted developer cluster
> > It might be useful to split this into individual packages for all the
> > various languages supported.
>
> We could consider splitting it into two pieces, C/C++ and the rest.
> Maintaining the cross dependencies could get complicated if we go any
> farther.
I don't think it would be too hard, and having separate packages for
different languages seems to match what Linux distributions do.
> >> SUNWgccruntime432 uncommitted core cluster
> >> SUNWscgfss432 uncommitted developer cluster, optimizing backend for Sparc
> >
> > Does this mean you plan to deliver the gccfss backend by default on SPARC,
> > instead of the regular GCC SPARC backend? This must be stated in the case.
>
> Both backends will be delivered on Sparc.
Good: which one will be the default and how can a user select the other?
Regards.
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
More information about the opensolaris-arc
mailing list