Rainer Orth wrote:
> George Vasick writes:
>
>> OK, got it. You will still see all of the normal gcc options. We provide
>> additional options targeted specifically at the Sun backend on SPARC as
>> well.
>
> What about GCC-style inline assembler? Does it work with the Studio
> backend just t
George Vasick writes:
> OK, got it. You will still see all of the normal gcc options. We provide
> additional options targeted specifically at the Sun backend on SPARC as
> well.
What about GCC-style inline assembler? Does it work with the Studio
backend just the same as with the GCC backend?
George Vasick wrote:
> Darren J Moffat wrote:
>> So will all possible code that the GNU backend can build also be able
>> to be built with the Studio backend ?
>
> "all possible" is a pretty big claim. The answer is a qualified yes. We
> designed the product to be 100% compatible. There is alw
Darren J Moffat wrote:
> So will all possible code that the GNU backend can build also be able to
> be built with the Studio backend ?
"all possible" is a pretty big claim. The answer is a qualified yes.
We designed the product to be 100% compatible. There is always a chance
somebody will fin
Bart Smaalders wrote:
> Bart Smaalders wrote:
>
>> If I use generic gcc for sparc and type ggc -c --help, I get a bunch
>> of output describing options that are interpreted by various stages
>> in the compilation and linking pipeline. Is any of this output
>> different w/ your code in place? In
So will all possible code that the GNU backend can build also be able to
be built with the Studio backend ? Are there any things that the GNU
backend can functionally do that the Studio one can't ?
Is there any difference in the CLI flags ? ie are there any flags that
would be passed to the GN
Bart Smaalders writes:
>>> Apart from the issues mentioned in my last mail (integrating 4.3.3
>>> instead of the current 4.3.4, defaulting to Studio backend on SPARC),
>>> this seems fine to me.
>>
>> I agreed, defaulting to the Studio backend is a really bad
>> idea. Including the Studio backend
Bart Smaalders wrote:
> If I use generic gcc for sparc and type ggc -c --help, I get a bunch
> of output describing options that are interpreted by various stages
> in the compilation and linking pipeline. Is any of this output
> different w/ your code in place? In what way?
Sigh... that of co
George Vasick wrote:
> It just occurred to me that my use of the term "backend" may be unclear.
> By backend, I mean the processing that occurs after scanning and
> parsing, typically optimization and code generation. To me, gas is an
> assembler. It comes after the compiler backend.
>
>
W
It just occurred to me that my use of the term "backend" may be unclear.
By backend, I mean the processing that occurs after scanning and
parsing, typically optimization and code generation. To me, gas is an
assembler. It comes after the compiler backend.
George
George Vasick wrote:
> Ba
Bart Smaalders wrote:
> George Vasick wrote:
>>> Bart Smaalders writes:
The question is one of compatibility to me... the provenance of the
backend seems irrelevant, but its interface is not.
>> Compatibility is extremely important. This will be our 6th release of
>> gcc for Sparc with
George Vasick wrote:
>> Bart Smaalders writes:
>>> The question is one of compatibility to me... the provenance of the
>>> backend seems irrelevant, but its interface is not.
> Compatibility is extremely important. This will be our 6th release of
> gcc for Sparc with the Sun backend as the defau
Rainer Orth wrote:
> Bart Smaalders writes:
>
Apart from the issues mentioned in my last mail (integrating 4.3.3
instead of the current 4.3.4, defaulting to Studio backend on SPARC),
this seems fine to me.
>>> I agreed, defaulting to the Studio backend is a really bad
>>> idea. Inc
Rainer Orth wrote:
> George Vasick writes:
>
>> Revised spec with requested changes attached.
>
> Apart from the issues mentioned in my last mail (integrating 4.3.3
> instead of the current 4.3.4, defaulting to Studio backend on SPARC),
> this seems fine to me.
I agreed, defaulting to the Studi
Darren J Moffat wrote:
> Rainer Orth wrote:
>> George Vasick writes:
>>
>>> Revised spec with requested changes attached.
>>
>> Apart from the issues mentioned in my last mail (integrating 4.3.3
>> instead of the current 4.3.4, defaulting to Studio backend on SPARC),
>> this seems fine to me.
>
>
George Vasick writes:
> Revised spec with requested changes attached.
Apart from the issues mentioned in my last mail (integrating 4.3.3
instead of the current 4.3.4, defaulting to Studio backend on SPARC),
this seems fine to me.
Thanks.
Rainer
--
George Vasick writes:
>> 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 th
Revised spec with requested changes attached.
Thanks,
George
George Vasick wrote:
> Rainer Orth wrote:
>> George Vasick writes:
>>
>>> Attached, please find the revision 3 of the GCC proposal addressing the
>>> following feedback:
>>
>> Thanks, looks much better overall.
>>
>>> 1) GCC should in
George Vasick 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/.
Darren already commented on this: I think this is meant to be
/usr/gcc/ instead, although the spec
Rainer Orth wrote:
> George Vasick 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/.
>
> Darren already commented on this: I think this is meant to be
George Vasick wrote:
> Attached, please find the revision 3 of the GCC proposal addressing the
> following feedback:
>
> 1) GCC should install in /usr/bin/gcc/.
I haven't been following this case that closely but that concerns me
deeply. /usr/gcc/bin// I understand but please don't add
new
Darren J Moffat wrote:
> George Vasick wrote:
>> Attached, please find the revision 3 of the GCC proposal addressing
>> the following feedback:
>>
>> 1) GCC should install in /usr/bin/gcc/.
That is a typo in the summary. The attachment shows the correct location:
/usr/gcc/4.3
Sorry about th
Corrected info for SUNWgccfss43:
Exported Interfaces Comments
===
SUNWgccfss43Sun backend components.
(SPARC only)
George Vasick wrote:
> One correction:
>
>> Exported InterfacesComments
>> ===
>> SUNWgccgccfssSun backend components.
The correct package name is also SUNWgccgccfss43
>> (SPARC only)
>>
One correction:
> Exported Interfaces Comments
> ===
> SUNWgccgccfss Sun backend components.
> (SPARC only)
>
Attached, please find the revision 3 of the GCC proposal addressing the
following feedback:
1) GCC should install in /usr/bin/gcc/.
2) Committed interfaces stability is too high and should be lowered to
uncommitted.
3) Gccfss components should be broken out into a separate package.
4) lib
Jyri Virkki wrote:
> George Vasick wrote:
>> I had expected collectd to use something like the postgres layout but it
>> seems to have followed another variant. This leaves me confused as to
>> what standard I should follow for gcc.
>
> The general discussion was about ".../$COMPONENT/$VERSION/
George Vasick wrote:
>
> I had expected collectd to use something like the postgres layout but it
> seems to have followed another variant. This leaves me confused as to
> what standard I should follow for gcc.
The general discussion was about ".../$COMPONENT/$VERSION/*" vs.
".../$COMPONENT$VER
Hi Jyri,
Thanks for the pointer to 2009/606.
I looked at the latest proposal sent this morning and noticed the file
layout is different than that used by postgres, one of the prime
examples people suggested I should follow for gcc.
Postgres puts most components under a single subdirectory:
/u
Hi George,
> I am actually on vacation this week but I do want to make progress on
> this one point regarding multiple versions:
fine.
> > Other than this objection, are there any reasons for going for the unusual
> > and hard to use versioning approach of adding version number suffixes to
> >
On Nov 13, 2009, at 7:39 AM, Rainer Orth wrote:
>> /usr/postgres/:
>> 8.2/
>> 8.3/
>>
>> I am happy to use whichever scheme is considered the correct
>> precedent.
>
> Fine: in fact I think this is a job for ARC, to provide guidance here.
This very question is a topic in 2009/606, also going on
George Vasick writes:
> George Vasick wrote:
> > ro at techfak.uni-bielefeld.de wrote:
> >> George Vasick writes:
> >>
> > [...]
> >
> >> 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 In
George Vasick writes:
> ro at techfak.uni-bielefeld.de wrote:
> > George Vasick writes:
> >
> >> Corrected a typo in the attachment. SUNWgccruntime432 will be deleted.
> >> SUNWgccruntime, which is part of GCC 3.4.3, will be retained.
> >>
> >> Thanks,
> >> George
> >>
> >> George Vasick wro
Hi Rainer,
I am actually on vacation this week but I do want to make progress on
this one point regarding multiple versions:
Rainer Orth wrote:
> George Vasick writes:
>
> [...]
>
>>
>> "The project team needs to either update the proposal to remove
>> /usr/compilers or I will derail this case
George Vasick wrote:
> ro at techfak.uni-bielefeld.de wrote:
>> George Vasick writes:
>>
> [...]
>
>> 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 InterfacesComments
>>> =
ro at techfak.uni-bielefeld.de wrote:
> George Vasick writes:
>
>> Corrected a typo in the attachment. SUNWgccruntime432 will be deleted.
>> SUNWgccruntime, which is part of GCC 3.4.3, will be retained.
>>
>> Thanks,
>> George
>>
>> George Vasick wrote:
>>> Please find a revised proposal atta
Stephen Hahn writes:
> > > This means we need verexec:
> > >
> > > http://blogs.sun.com/sch/entry/verexec_1_a_simple_execute
> >
> > Interesting, although I see a couple of problems (and haven't followed
> > pkg-discuss due to its enormous volume). One thing is obvious, though:
> > even with ve
The compiler project team has promised in spoken and written word to
deliver Ada support with the next case. LSARC/2009/575 is this next
case.
Should a project team allowed to promise a place in heaven, later
break their word and get away with this?
2009/11/5 Rainer Orth :
> =?KOI8-R?B?z8zYx8Egy9L
=?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= writes:
> Ada language support was not addressed, too. This is the second time
> the compiler project team is not implementing support.
I think this (and Java support) could and should be separate cases. Most
likely, the community can help here. Especially
Ada language support was not addressed, too. This is the second time
the compiler project team is not implementing support.
How do I appeal a PSARC case?
On Thu, Nov 5, 2009 at 7:04 PM, wrote:
> George Vasick writes:
>
>> Corrected a typo in the attachment. SUNWgccruntime432 will be deleted.
George Vasick writes:
> Corrected a typo in the attachment. SUNWgccruntime432 will be deleted.
> SUNWgccruntime, which is part of GCC 3.4.3, will be retained.
>
> Thanks,
> George
>
> George Vasick wrote:
> > Please find a revised proposal attached addressing the following feedback:
> >
>
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 consolidatio
Bart Smaalders writes:
> George Vasick wrote:
> > Yes, you are 100% corrected on the studio side. For gcc, the build uses
> > the compiler installed on the live system. I don't know why the two are
> > handled differently. We do need to accommodate Solaris builds, however.
> > They are one
* Rainer Orth [2009-11-05 16:34]:
> Bart Smaalders writes:
>
> > George Vasick wrote:
> > > Yes, you are 100% corrected on the studio side. For gcc, the build uses
> > > the compiler installed on the live system. I don't know why the two are
> > > handled differently. We do need to accommoda
? wrote:
> Ada language support was not addressed, too. This is the second time
> the compiler project team is not implementing support.
>
> How do I appeal a PSARC case?
First the case has to be completed. In the case of missing language
support, I don't see anything to appeal
major concerns that are still not
> addressed, please speak up.
>
> Thank you,
> Raj
>
> Original Message --------
> Subject: Re: GCC4: The GNU Compiler Collection 4.X [LSARC/2009/575
> FastTrack timeout 10/28/2009]
> Date: Thu, 29 Oct 2009 08:
On 10/29/09, Raj Prakash wrote:
> Hello,
>
> It looks like George's updated proposal takes into account most of the
> discussion so far on the case. I am resetting the timeout to this Friday,
> Oct 30. If you have any major concerns that are still not addressed, please
> speak up.
Major concern:
ssage
Subject: Re: GCC4: The GNU Compiler Collection 4.X [LSARC/2009/575
FastTrack timeout 10/28/2009]
Date: Thu, 29 Oct 2009 08:22:45 -0700
From: George Vasick
To: George Vasick
CC: LSARC-ext at sun.com, Raj Prakash ,
Raj.Prakash at Sun.COM
Corrected a typo in the attac
Corrected a typo in the attachment. SUNWgccruntime432 will be deleted.
SUNWgccruntime, which is part of GCC 3.4.3, will be retained.
Thanks,
George
George Vasick wrote:
> Please find a revised proposal attached addressing the following feedback:
>
> 1) Versioning should be major.minor, not
Please find a revised proposal attached addressing the following feedback:
1) Versioning should be major.minor, not major.minor.micro.
2) usr/share/man7 contents should be moved to usr/share/man5.
3) choosing which compiler is invoked by default, e.g./usr/bin/gcc.
Thanks,
George
On Mon, Oct 26, 2009 at 10:30 AM, George Vasick
wrote:
> OK, let me make sure I understand correctly.
>
> In OpensSolaris 2009.06, we should have released gcc43 as opposed to gcc432.
My understanding is that that is the norm for the extended the GCC
community - that the "trailing .2" is simply
John Plocher wrote:
> On Fri, Oct 23, 2009 at 6:29 PM, George Vasick
> wrote:
>> In the previous case for 4.3.2, we had proposed adding "plain" links in
>> /usr/bin to the default version of GCC, e.g. /usr/bin/gcc -> gcc-4.3.2.
>> According to the gcc man page, plain gcc should invoke the last v
On Fri, Oct 23, 2009 at 6:29 PM, George Vasick wrote:
> In the previous case for 4.3.2, we had proposed adding "plain" links in
> /usr/bin to the default version of GCC, e.g. /usr/bin/gcc -> gcc-4.3.2.
> ?According to the gcc man page, plain gcc should invoke the last version
> installed.
I'd lik
George Vasick wrote:
> Alan Coopersmith wrote:
>> Raj Prakash wrote:
>>> usr/share/man/man7
>>> usr/share/man/man7/fsf-funding.7
>>> usr/share/man/man7/gfdl.7
>>> usr/share/man/man7/gpl.7
>>
>> Since those are not device drivers, the miscellaneous topics man pages
>> belong in secti
typo corrected.
Alan Coopersmith wrote:
> Raj Prakash wrote:
>> usr/share/man/man7
>> usr/share/man/man7/fsf-funding.7
>> usr/share/man/man7/gfdl.7
>> usr/share/man/man7/gpl.7
>
> Since those are not device drivers, the miscellaneous topics man pages
> belong in section 5 on S
Alan Coopersmith wrote:
> Raj Prakash wrote:
>> usr/share/man/man7
>> usr/share/man/man7/fsf-funding.7
>> usr/share/man/man7/gfdl.7
>> usr/share/man/man7/gpl.7
>
> Since those are not device drivers, the miscellaneous topics man pages
> belong in section 5 on SysV-based platfor
Norm Jacobs wrote:
> George Vasick wrote:
>> Norm Jacobs wrote:
>>> Raj Prakash wrote:
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
GCC4: The GNU Compiler Collection 4.X
4. Technical Description
John Plocher wrote:
> Didn't we have this very same coexistence conversation the first time
> 'round? :-)
>
> The use case of the user installing gcc 4.3.2 "yesterday", installing
> gcc 4.3.3 "today", and then uninstalling gcc 4.3.2 "tomorrow" is going
> to be a reasonably common upgrade path; wha
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
George Vasick wrote:
> Norm Jacobs wrote:
>> Raj Prakash wrote:
>>>
>>> This information is Copyright 2009 Sun Microsystems
>>> 1. Introduction
>>>1.1. Project/Component Working Name:
>>> GCC4: The GNU Compiler Collection 4.X
>>>
>>> 4. Technical Description:
>>>4.1. Details:
>>> C
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
Norm Jacobs wrote:
> Raj Prakash wrote:
>>
>> This information is Copyright 2009 Sun Microsystems
>> 1. Introduction
>>1.1. Project/Component Working Name:
>> GCC4: The GNU Compiler Collection 4.X
>>
>> 4. Technical Description:
>>4.1. Details:
>> Commands will be installed in /usr
Raj Prakash wrote:
>
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
>1.1. Project/Component Working Name:
> GCC4: The GNU Compiler Collection 4.X
>
> 4. Technical Description:
>4.1. Details:
> Commands will be installed in /usr/bin with versioned suffixes,
George Vasick writes:
> We released 4.3.2 in OpenSolaris 2009.06. We have to update 4.3.2 in
> order to release 4.3.3 to avoid duplicate pathnames between the packages.
Is this relevant at all? Has this ever been ARCed? If not, it might as
well not exist ;-)
Rainer
--
On 10/22/09, George Vasick wrote:
> Alan Coopersmith wrote:
>
> > George Vasick wrote:
> >
> > > Alan Coopersmith wrote:
> > >
> > > > You really need both 4.3.2 & 4.3.3?
> > > >
> > > My first choice would have been to replace the current gcc 3.4.3 with
> > > gcc 4.X and simply called it gcc. Ho
On 10/22/09, George Vasick wrote:
> Solaris freezes on a specific release for its build compiler. What happens
> when they are on 4.x.y and we want to release 4.x.z?
You are dead wrong: gcc releases are x.y, not 4.x.y or x.y.z. The last
element in the triple is serial number for bug fix release
George Vasick writes:
> Alan Coopersmith wrote:
> > You really need both 4.3.2 & 4.3.3?
>
> My first choice would have been to replace the current gcc 3.4.3 with
> gcc 4.X and simply called it gcc. However, gcc 3.4.3 is part of the
> Solaris build environment and we must keep it until Solaris
=?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= writes:
> Raj, I can't find libdecnumber.so in the case materials. Are you
> disabling decimal floating point support on Solaris?
No, this is only enabled on specific platforms, but disabled by default. I
haven't yet tried if it works on Solaris (SPARC and/
=?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= writes:
> In my option shipping both 4.3.3 and 4.3.2 is wasted time. 4.3.3 is a
> bug fix only update to 4.3.2. You better invest the time in shipping
Indeed, and there exists even 4.3.4 by now.
> the Ada frontend and runtime libraries.
Right: I had alread
Raj, I can't find libdecnumber.so in the case materials. Are you
disabling decimal floating point support on Solaris?
On 10/22/09, Raj Prakash wrote:
>
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
>1.1. Project/Component Working Name:
> GCC4: The GNU Comp
On 10/22/09, Alan Coopersmith wrote:
> You really need both 4.3.2 & 4.3.3? You don't believe even
> micro releases are not safe or compatible upgrades?That's
> just sad, and somewhat inconsistent with every other distro/OS
> shipping gcc I've seen. (3.4.3 vs. 4.3.3, sure, but not
> 4.3
George Vasick wrote:
> Yes, you are 100% corrected on the studio side. For gcc, the build uses
> the compiler installed on the live system. I don't know why the two are
> handled differently. We do need to accommodate Solaris builds, however.
> They are one of our important users.
This is e
Rainer Orth wrote:
> George Vasick writes:
>
>> Alan Coopersmith wrote:
>>> You really need both 4.3.2 & 4.3.3?
>> My first choice would have been to replace the current gcc 3.4.3 with
>> gcc 4.X and simply called it gcc. However, gcc 3.4.3 is part of the
>> Solaris build environment and we mu
Didn't we have this very same coexistence conversation the first time
'round? :-)
The use case of the user installing gcc 4.3.2 "yesterday", installing
gcc 4.3.3 "today", and then uninstalling gcc 4.3.2 "tomorrow" is going
to be a reasonably common upgrade path; whatever causes the "havoc to
both
Nicolas Williams wrote:
> On Thu, Oct 22, 2009 at 01:37:13PM -0700, George Vasick wrote:
>> Alan Coopersmith wrote:
>>> You really need both 4.3.2 & 4.3.3?
>> Solaris freezes on a specific release for its build compiler. What
>> happens when they are on 4.x.y and we want to release 4.x.z?
>
> Ju
Rainer Orth wrote:
> George Vasick writes:
>
>> We released 4.3.2 in OpenSolaris 2009.06. We have to update 4.3.2 in
>> order to release 4.3.3 to avoid duplicate pathnames between the packages.
>
> Is this relevant at all? Has this ever been ARCed? If not, it might as
> well not exist ;-)
Y
Raj Prakash 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
Alan Coopersmith wrote:
> George Vasick wrote:
>> We released 4.3.2 in OpenSolaris 2009.06. We have to update 4.3.2 in
>> order to release 4.3.3 to avoid duplicate pathnames between the packages.
>
> The case specified 4.3.2 as a new delivery, not something already provided.
Sorry about that. H
Octave Orgeron wrote:
> Hi,
>
> Shouldn't GCC be installed into /usr/gnu and then linked back into /usr/bin,
> /usr/lib, etc?
No. The rules for /usr/gnu/bin are that a binary only needs to go there
if its normal name clashes with an existing entry in /usr/bin that it
can not completely (ie wi
Alan Coopersmith writes:
> You really need both 4.3.2 & 4.3.3? You don't believe even
> micro releases are not safe or compatible upgrades?That's
> just sad, and somewhat inconsistent with every other distro/OS
> shipping gcc I've seen. (3.4.3 vs. 4.3.3, sure, but not
> 4.3.2 vs. 4.3.3.)
On Thu, Oct 22, 2009 at 01:37:13PM -0700, George Vasick wrote:
> Alan Coopersmith wrote:
> >You really need both 4.3.2 & 4.3.3?
>
> Solaris freezes on a specific release for its build compiler. What
> happens when they are on 4.x.y and we want to release 4.x.z?
Just because the ONNV and/or othe
George Vasick wrote:
> We released 4.3.2 in OpenSolaris 2009.06. We have to update 4.3.2 in
> order to release 4.3.3 to avoid duplicate pathnames between the packages.
The case specified 4.3.2 as a new delivery, not something already provided.
Still, it seems wasteful to ship both, instead of rep
Raj Prakash wrote:
> usr/share/man/man7
> usr/share/man/man7/fsf-funding.7
> usr/share/man/man7/gfdl.7
> usr/share/man/man7/gpl.7
Since those are not device drivers, the miscellaneous topics man pages
belong in section 5 on SysV-based platforms like Solaris, instead of
the
Alan Coopersmith wrote:
> George Vasick wrote:
>> Alan Coopersmith wrote:
>>> You really need both 4.3.2 & 4.3.3?
>> My first choice would have been to replace the current gcc 3.4.3 with
>> gcc 4.X and simply called it gcc. However, gcc 3.4.3 is part of the
>> Solaris build environment and we must
George Vasick wrote:
> Alan Coopersmith wrote:
>> You really need both 4.3.2 & 4.3.3?
>
> My first choice would have been to replace the current gcc 3.4.3 with
> gcc 4.X and simply called it gcc. However, gcc 3.4.3 is part of the
> Solaris build environment and we must keep it until Solaris moves
Alan Coopersmith wrote:
> You really need both 4.3.2 & 4.3.3?
My first choice would have been to replace the current gcc 3.4.3 with
gcc 4.X and simply called it gcc. However, gcc 3.4.3 is part of the
Solaris build environment and we must keep it until Solaris moves to a
newer version of gcc.
-Mail: unixconsole at yahoo.com
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
- Original Message
From: Raj Prakash
To: LSARC-ext at sun.com
Sent: Thu, October 22, 2009 12:35:39 AM
Subject: GCC4: The GNU Compiler Collection 4.X [LSARC/2009/575 FastTrack
timeout
You really need both 4.3.2 & 4.3.3? You don't believe even
micro releases are not safe or compatible upgrades?That's
just sad, and somewhat inconsistent with every other distro/OS
shipping gcc I've seen. (3.4.3 vs. 4.3.3, sure, but not
4.3.2 vs. 4.3.3.)
--
-Alan Coopersmith-
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
GCC4: The GNU Compiler Collection 4.X
1.2. Name of Document Author/Supplier:
Author: George Vasick
1.3 Date of This Document:
21 October, 2009
4. Technic
89 matches
Mail list logo
