GNU Developer Collection [LSARC/2008/776 FastTrack timeout 01/07/2009]
George Vasick
George.Vasick at sun.com
Wed Jan 7 16:24:23 PST 2009
Rainer Orth wrote:
> 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.
Is there a business case for adding GCJ or GNAT? Are there any RFEs or
VOC data?
>
>>>> 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.
The concern is that we do not own these packages and cannot ensure
compatibility. Our proposed scheme allows multiple versions to coexist
if a compatibility problem were to come up. We can also get rid of old
versions and add soft links in the cases where the new version is
completely compatible with the previous versions, e.g binutils219 could
be a link to binutils220.
>
>> 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.
Actually, we are proposing to to install binutils 2.19 in
/usr/compilers/binutils219. It will be a separate package and not
contained in /usr/compilers/gcc432.
>
>>> 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.
We have links packages defined to solve the PATH problem for users.
These packages will link the desired version of the compilers and tools
to /usr/bin and /usr/gnu/bin.
>
>>>> 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.
I have changed interfaces to uncommitted.
>
>>> 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?
We have left the .la file in. We will check for any existing 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?
We have removed the .a files from our test builds. We haven't seen a
problem yet, but we will investigate.
>
>>>> 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.
The current packages do seem overly large, about 135 MB on x86. We
propose to keep it a single package.
>
>>>> 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?
The default is the Studio backend. There is a flag to specify the stock
GCC backend.
Thanks,
George
>
> Regards.
> Rainer
>
> -----------------------------------------------------------------------------
> Rainer Orth, Faculty of Technology, Bielefeld University
More information about the opensolaris-arc
mailing list