Sorry for the late replies: I had connectivity problems during OSDevCon in
Dresden and much less time than expected, so only now catching up on my
mail.
George Vasick writes:
> Rainer Orth wrote:
> > George Vasick writes:
> >
> >>> How's the progress with moving ON (and perhaps other consolidations, I
> >>> don't know if they use GCC at all or rather prefer the Studio compilers)
> >>> from GCC 3 to GCC 4?
> >> Delayed a little. We lost a resource recently and we are still playing
> >> catch up.
> >
> > Couldn't this be handled as an OpenSolaris project? Then community members
> > could help.
>
> That would be great! How do we get it started?
This is explained on
http://hub.opensolaris.org/bin/view/Main/projects
I suggest using the ON and Tools communities as sponsors.
> >>> This may be a point where we have to say: this might have to be Sun's
> >>> problem, not the communities, especially if the current solution is so
> >>> incompatible with the way any other product is handled. This would be an
> >>> issue for my other examples as well: how do you handle this e.g. in
> >>> PostgreSQL? Or just let those customers not update they GCC installation
> >>> and keep it the way it is.
> >> I don't see the incompatibility for users with just one gcc version
> >> installed. For users who need multiple versions for what ever reason,
> >> we'd like to provide that capability.
> >
> > The incompatibility (and resulting user confusion) lies in the fact that
> > you provide different micro versions in parallel without any rational, were
> > other projects provide only minor versions and update those to newer
> > compatible micro version as they see fit. I don't see why a user should
> > care if he's using gcc 4.3.2 or 4.3.3. I can understand wanting to use
> > 4.3.x instead of (say) 4.4.x if there are problems/incompatibilities. In
> > addition, your way of handling the version is different from anybody
> > else's, again without any rational at all. Beyond this, you don't provide
> > a default version at all (leaving that at 3.4.3 at best). I'm not arguing
> > against providing different versions in parallel (quite the contrary), but
> > do this like any other project, at the granularity of minor versions, and
> > provide a default version.
>
> Maybe I misunderstood the concerns on this versioning thing. Are you
> concerned about the suffixes on the commands themselves, i.e. gcc-4.3.3,
> g++-4.3.3, etc., as opposed to the internals, like usr/lib/gcc/4.3.3/
> and i386-pc-solaris2.11-gcc-4.3.3?
Right: this version suffix is a non-standard scheme and will cause much
trouble for anyone wanting to use a particular version of GCC. Instead of
just pointing PATH at that directory and be done with it for all commands
delivered by that version of the GCC packages, he'll have to set several
make variables to point to the specific commands, something like make
CC=gcc-4.3.2 CXX=g++-4.3.2 and perhaps several more. This is unfamiliar,
user unfriendly and prone with error.
> If it is only the former, we could use something gcc4 or gcc43 for the
> commands. Currently, /usr/bin/[gcc,g++,g77,etc.] are taken by the gcc
Same problem: why not follow the lead of every other package that does
parallel delivery of several versions and use something like
/usr/gcc/4.3/bin/gcc etc?
> 3.4.3 package on OpenSolaris and not available for use by gcc 4.x.
This may be true in Indiana, but hasn't been ARCed and is thus only
partially (if at all) relevant here. Even so, you could decide to keep
/usr/sfw/bin/gcc (and /usr/bin/gcc) at 3.4.3 for the moment and just
deliver 4.3.x in parallel.
As I said, if ON or other consolidations have specific build requirements,
there's no decree that they need to use the compiler included with the base
system as is. They already don't for Sun Studio, and could require a
separate delivery for GCC as well.
You could even re-deliver GCC 3.4.3 into /usr/gcc/3.4 instead so it is
easily available for those consoliations.
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
