Raj Prakash <Raj.Prakash at sun.com> writes:
> 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:
> Commands will be installed in /usr/bin with versioned suffixes,
> e.g. gcc-4.3.2. The runtime libraries will be installed
This is the wrong way to do this: apart from the parallel delivery of two
micro versions of the same minor version (4.3.2 and 4.3.3) without giving
any reason, this delivery of commands with micro version numbers appended
is almost unprecedented: every other project (e.g. PostgreSQL, MySQL or
Apache 2) deliver at most minor versions in parallel while transparently
updating micro versions as they see fit, and in parallel directory
hierarchies (like /usr/postgres/8.[23]) instead of appending micro version
numbers to binaries in /usr/bin. This has several disadvantages:
* It is different than any other similar project in Solaris, setting a
precedent without any justification.
* It leaves the user without a default version of gcc to be invoked by that
name: if they happen to have /usr/sfw/bin in PATH, the get GCC 3.4.6
instead and assume 4.3 isn't there at all. If one wants to use GCC 4.3,
one needs to build one's projects with CC=gcc-4.3.2 or CC=gcc-4.3.3,
where almost no user will care about the micro release difference. Given
the GCC project's own compatibility requirements, only bug fixes may go
into micro release, so they should be compatible.
Instead, I propose (as I've already done within a previous GCC 4 case) to
follow the lead of all other projects and deliver
/usr/gcc/4.3/bin
lib
...
4.4/bin
and symlink one of those versions into /usr/bin without any suffix,
declaring it the default. This is already familiar from other projects,
provides a default version (to be decided, but either 4.3.[34] or 4.4.1 at
this point) for those who don't care about this detail, but provides access
to different versions if this proves necessary.
> /usr/lib with major, minor, and patch 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.
This makes sense: one should run the testsuites of earlier versions with
the later libraries to make sure that at least there no regressions show
up, but this is up to the engineer performing the testing and integration.
> See section 4.5 Interfaces below for additional details.
>
> This case proposes to modify the previous release,
> LSARC/2008/776 GNU Developer Collection, as follows:
>
> 1) Localized message files will be moved from /usr/share/locale
> to /usr/lib/gcc/<machine>/<version>/share/locale.
Makes sense and is necessary to deliver different versions with different
message catalogs in parallel.
> 2) Runtime libraries will be refactored from a single package
> into multiple packages, one package per library, to allow
> individual libraries to be upgraded in future releases.
Fine, also for those who only want to run gcc/g++/gfortran compiled
binaries without installing the whole compiler suite.
> 4.5. Interfaces:
>
> Exported Interfaces Comments
> =================== ========
> SUNWgcc432 GCC 432 compiler package.
As I said above, this should be SUNWgcc43 instead.
> usr/lib/gcc/<machine>/gccfss/4.3.2/LEGAL/* Sparc only.
> usr/lib/gcc/<machine>/gccfss/4.3.2/prod/* Sparc only.
You should provide some details about this: how is this used, and what is
in there? I think this belongs into its own package.
> Exported Interfaces Comments
> =================== ========
> SUNWgcclibgcc1 Low level runtime library
> package.
> All interfaces Committed.
I'm pretty certain Committed is too much, even though the GCC project cares
very much about interface compatibility here. I'd leave it as Uncommitted
instead.
> Exported Interfaces Comments
> =================== ========
> SUNWgcclibgfortran3 Fortran runtime library package.
> All interfaces committed.
Same here: Uncommitted is probably ok.
> Exported Interfaces Comments
> =================== ========
> SUNWgcclibgomp1 OpenMP runtime library package.
> All interfaces Committed.
Even Uncommitted my be too high; I'm not sure about the stability and
standardisation level of OpenMP and libgomp at this point.
> usr/lib/libgomp.so.1=libgomp.so.1.0.0
> usr/lib/libgomp.so.1.0.0
> usr/lib/libgomp.spec
> usr/lib/<mach64>/libgomp.so.1=libgomp.so.1.0.0
> usr/lib/<mach64>/libgomp.so.1.0.0
> usr/lib/<mach64>/libgomp.spec
I don't think the libgomp.spec files are used at runtime, but only by the
compiler driver. Why are they in here?
> Exported Interfaces Comments
> =================== ========
> SUNWgcclibobjc2 Objective C runtime library
> package.
> All interfaces Committed.
Maybe Uncommitted, but I'm not sure. Lack of change may well be due to
lack of maintenance here.
> Exported Interfaces Comments
> =================== ========
> SUNWgcclibssp0 Stack Smashing Protection
> runtime library package.
> All interfaces Committed.
Committed is far too high: this may well be Volatile at this point. It is
quite new and I have no idea about the intended stability here.
> Exported Interfaces Comments
> =================== ========
> SUNWgcclibstdc6 C++ runtime library package.
> All interfaces Committed.
Probably Uncommitted: should be ok since the libstdc++ projects works on a
separate branch on a major version upgrade which will break ABI
compatiblity at some point.
> Imported Interfaces
> ===================
> binutils
Which parts of binutils are used? GNU as on x86, but Sun as on SPARC? It
should be possible to use Sun as on x86/x64, but probably only in GCC 4.4.
> ld
I hope you use Sun ld everywhere!
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
