George Vasick writes:
[It may be better to remove gcc2ir at Sun.COM from the Cc: all mails to that
address bounce for posters external to Sun.]
> > 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
I think my experiment has demonstrated compatibility for the purposes of
GCC. Is there any evidence that other OSes have parallel binutils
installations?
> 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.
As I said, apart from blatant bugs (which could be avoided by either not
including buggy versions in OpenSolaris or, better yet, properly testing
them *before release*, i.e. becoming part of the binutils community), I
know of no incompabitilities. Even so, they won't affect GCC because the
compiler tests for new assembler and linker features at build time.
> >> 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.
Again, my questions about the reasons for that haven't been answered yet:
* Why /usr/compilers at all? We don't have /usr/webservers or
/usr/databases.
* Why /usr/compilers/gcc432 instead of /usr/gcc43? GCC rules reasonably
ensure compatibility at the micro version level, and e.g. postgres has
done micro version updates without changing pathnames in such a way.
This just makes it harder for users of a particular minor version to keep
using that in the face of updates.
> 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.
This just establishes default versions in /usr/bin and /usr/gnu/bin. If a
user wants to use say gcc 4.3 specificially, in your scheme he needs to
update his path from /usr/compilers/gcc432 to /usr/compilers/gcc433 in case
you ship an update to that micro version to fix some important bugs.
Inconvenient and completely unnecessary.
> > 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.
Ok, thanks. It is certainly possible to raise the classification of
e.g. libgcc_s.so.1 in the future; I'm not completely sure if there are
libraries which would better be volatile. It would take some amount of
investigation to check for this.
> >>>> 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.
I suppose you mean `don't seem' here? I find this unfortunate, since it
neither matches Sun Studio practice (which has separate patches for
different languages and runtime libraries) nor (as I mentioned) Linux
practice.
> >>>> 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.
How does this affect e.g. GCC features and testsuite results? It might be
better to have the stock GCC SPARC backend as the default, for feature
parity between SPARC and x86/x64, and have gccfss as an option.
Rainer
