Raj Prakash <Raj.Prakash at sun.com> writes:
> Sun Proprietary/Confidential: Internal Use Only: Engineering Need-to-Know
This seems inappropriate for an open case.
> 1.5.4. Interest List: <gccfss-interest at sun.com>
Why not using compilers-discuss at opensolaris.org? Where's the relation to
gccfss, which is (at least right now) SPARC-only?
> 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)?
Objective C++ may be inappropriate, on the other hand: it is not built by
default, its future maintenance is highly uncertain, so it may be better
not to include it in the first place.
> - GNU Binutils includes a collection of binary tools, the most notable
> being the assembler and linker.
Does this mean that GCC will be using GNU as and ld instead of the native
tools? At the very least, use of GNU ld is highly questionable since it
lacks many features of Sun ld.
> 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?
Apart from that, I see no reason to make this micro-version dependant: the
libraries remain ABI compatible inside a minor release.
> 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).
> /usr/compilers/gcc432/lib/libmudflap.la
> /usr/compilers/gcc432/lib/libmudflap.so
> /usr/compilers/gcc432/lib/libmudflap.so.0
> /usr/compilers/gcc432/lib/libmudflap.so.0.0.0
> /usr/compilers/gcc432/lib/libmudflapth.la
> /usr/compilers/gcc432/lib/libmudflapth.so
> /usr/compilers/gcc432/lib/libmudflapth.so.0
> /usr/compilers/gcc432/lib/libmudflapth.so.0.0.0
libmudflap currently depends on GNU ld features, which would indicate that
GCC will be built with GNU ld.
Btw., what's the reason to deliver libtool .la files? They often seem to
cause more trouble than they are worth.
> The following soft links will be created in /usr/bin to point to
> /usr/compilers/gcc432/bin
[...]
> /usr/bin/gprof
This is already delivered by SUNWbtool. Are the two completely compatible?
> All libs in /usr/compilers/gcc432/lib and
> /usr/compilers/gcc432/lib/{MACH64}
> will be linked into /usr/lib and /usr/lib/{MACH64}.
This doesn't make sense to do unconditionally:
* We don't deliver *.la files in /usr/lib.
* libbfd-2.19.so is volatile and (at most) used to reduce the size of the
delivered binutils. This doesn't belong in any public place, if it is
used at all (N.B. by default GNU binutils are built with
--disable-shared).
* 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?
> 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.
> SUNWbinutils2_19 uncommitted developer cluster
The usual convention is to use SUNWbinutils219, i.e. withouth the underscore.
> 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.
> 5. Reference Documents:
> -
> http://dptwiki.sfbay.sun.com/twiki/bin/view/Compiler/GNUDeveloperCollection
This is not visible outside SWAN!
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
