George Vasick <George.Vasick at Sun.COM> writes:
> Attached, please find the revision 3 of the GCC proposal addressing the
> following feedback:
Thanks, looks much better overall.
> 1) GCC should install in /usr/bin/gcc/<major.minor>.
Darren already commented on this: I think this is meant to be
/usr/gcc/<major.minor> instead, although the spec uses both forms.
Please clarify.
> 2) Committed interfaces stability is too high and should be lowered to
> uncommitted.
Seems right for the moment (perhaps with the exception of libssp), but
as I mentioned this is an area where more work needs to be invested into
GCC in the future: e.g. libstdc++ uses version maps to only expose
public symbols, but that requires GNU ld features at the moment. I'll
check with the Sun linker guys what do do about this.
> 3) Gccfss components should be broken out into a separate package.
>
> 4) libgomp.spec should be moved to version specific location.
Good.
> Issues not addressed directly in the updated proposal:
>
> Issue 1:
> One additional issue occurred to me in the meantime: does it really make
> sense to deliver every version of the runtime libs in its own package,
> rather than having separate packages for (say) all libstdc++ runtime libs
> together?
>
> Response:
> Runtime library packages are versioned only by their major number. There
> will not be multiple packages for various minor and micro versions of the
> libraries. For example, GCC 4.3.3 includes libstdc++.so.6.0.10 while GCC
> 4.4. includes libstdc++.so.6.0.13. The current version of SUNWgcclibstdc6
> will contain libstdc++.so.6.0.10. When we release GCC 4.4, the
> SUNWgcclibstdc6 will be updated to contain libstdc++.so.6.0.13. At any
> point, SUNWgcclibstdc6 will only include the latest version of
> libstdc++.so.6.x.y.
I never assumed otherwise. Even so, it may be an option to have only a
single package delivering libstdc++.so.6 and (say) libstdc++.so.7
instead of splitting, just like the Studio compilers deliver all major
versions of libF77.so in SPROl77sx. I don't really think users know
(and care) about specific shared library to be installed separately.
> Issue 2:
> It's obvious you're including gccfss, but what are the consequences? Do
> you replace the GCC SPARC backend by the Sun backend here? This may not be
> appropriate, since this heavily deviates from the upstream FSF GCC, and may
> cause problems. Have you run the GCC testsuite this way and compared the
> results to those with the GCC backend? I think it should be possible for
> the user to select between gccfss and the regular GCC backend here.
>
> Response:
> We provide both the GCC backend and the Sun backend. We include the GCC
> testsuite in our testing of the Sun backend. The user is able to invoke
> the GCC backend under flag control.
How does this work (i.e. which flags are used), and what is the default?
> Issue 3:
> I hope you use Sun ld everywhere!
>
> Response:
> Yes.
>
>
> Are there any other questions or concerns that I missed?
I don't remember any.
> 1. Introduction
> 1.1. Project/Component Working Name:
> GCC4: The GNU Compiler Collection 4.X
Perhaps this should be changed to GCC 4.3? I expect there will be
similar cases for GCC 4.4 in the future, so it's better to distinguish
them, especially if future cases add additional languages, like Ada and
Java.
> 2. Project Summary
> 2.1. Project Description:
> Provide GCC 4.X and allow for the coexistence of multiple
> versions of GCC installed simultaneously.
>
> GCC 3.4.3, the current build compiler for OpenSolaris and
> Nevada, will remain unchanged in /usr/sfw.
>
> 4. Technical Description:
> 4.1. Details:
> Versions of GCC will be installed in /usr/gcc/<major.minor>, in
> this case /usr/bin/gcc/4.3/[bin, lib, include,info, man,
> share]. The runtime libraries will be installed /usr/lib with
> major, minor, and micro suffixes as appropriate along with a
> link for the major version, e.g libstdc++.so.6.0.10 and
> libstdc++.so.6 -> libstdc++.so.6.0.10. See section 4.5
> Interfaces below for additional details.
>From the file list, it seems like you will be integrating GCC 4.3.3?
Why not go straight to the latest 4.3 release, 4.3.4?
> 4.5. Interfaces:
>
> Exported Interfaces Comments
> =================== ========
> SUNWgcc4 Latest GCC installed.
> All interfaces Uncommitted.
> usr/bin/c++ symlink to latest c++
> usr/bin/cpp symlink to latest cpp
> usr/bin/g++ symlink to latest g++
> usr/bin/gcc symlink to latest gcc
> usr/bin/gccbug symlink to latest gccbug
The email submission of GCC bugs hasn't worked for a long time and the
GCC project doesn't seem inclined to fix this any time soon, so it would
be better to not link gccbug into /usr/bin at the moment.
> Exported Interfaces Comments
> =================== ========
> SUNWgcc43 GCC 4.3.X package.
> All interfaces Uncommitted.
>
> usr/gcc/4.3/lib/<mach64>/libobjc_gc.so=../../../../lib/<mach64>/libobjc_gc.so.2
You seem to be configuring GCC with --enable-objc-gc, which is not the
default? Why?
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
