RE: Fyi

RE: Fyi

[wade.zhang]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]



Donation for you and your family , email me back ASAP

FYI

[UNITED NATIONS]

Contact Bank Zachodni WBK Poland for your UN Compensation draft worth $550,000.00

FYI

[Igor Markov]

  I mailed to Michael Johnson of RedHat sometime ago re: the RPMs
  for gcc and also contacted (many hrs ago) a guy who builds new RPMs
  daily and announces them on a redhat mailing list.

  My point was that it would have been a prudent measure for the 
  egcs group and cygnus support to establish such contacts earlier...
  apparently you are of a difft opinion; oh well...

  It's probably even less effort than typing replies to my emails ;)

								Igor
-- 
  Igor Markov  office: (310) 206-0179   
  http://vlsicad.cs.ucla.edu/~imarkov

Re: FYI

[Christopher C Chimelis]

On Wed, 4 Aug 1999, Igor Markov wrote:

>   hmmm... I have been working with SunPro CC as a C++ compiler
>   for years because g++ could not compile C++ code that I wrote.
>   MSVC++ is another problem our lab supports.

Hehehe..yes, MSVC++ can be a difficult animal itself :-)

>   Now, with the new release of gcc, we planned to maintain the code
>   with g++ in addition to those two. I spent half a day overall and
>   discovered a strange but apparent ignorance of final users that 
>   the gcc team has. We will have to wait until the smoke clears and
>   personal ambitions settle down.

I can understand this....

>   Finally, Chris, I appreciate your efforts to interpret emails to
>   the two parties, but I can only stand by what I wrote ----
>   I am pretty sure that PCs dominate general purpose computers,
>   and that, independently, RedHat is dominating Linux installations --
>   I saw this published ;-)  (I think you slightly misquoted me on this)

I probably did :-) At any rate, the one thing that I think RedHat
consistantly overlooks is binary package dependencies (which Debian has,
believe me, this is not to toot our horn, just an example).  I think alot
of the misbuilt RPMs that I've run into relate to this.  In this case, I'm
pretty sure that ignorance of that issue, coupled with lack of general
knowledge on the packager's part (hence the ownership issues) and also
lack of general libtool knowledge (argh) probably defeated that set of
RPMs.  I would strongly recommend building it from source for two reasons:
ensuring that nothing was "added" to the RPMs in question and also so that
you can tailor the installation to your particular systems.  I have a more
than rudimentary understanding of gcc and the RPM format, but wouldn't
even attempt making a set of RPMs unless I was POSITIVE that I could make
them as portable as possible (obviously something overlooked by the
packager of the RPMs in contrib).

At any rate, I'll bow out of this discussion again :-)  I understand both
sides, but I would tend to agree with the "build it from the source"
advice on the list (I know I usually do, having an EV56 Alpha).

C

Re: FYI

[Igor Markov]

  hmmm... I have been working with SunPro CC as a C++ compiler
  for years because g++ could not compile C++ code that I wrote.
  MSVC++ is another problem our lab supports.

  Now, with the new release of gcc, we planned to maintain the code
  with g++ in addition to those two. I spent half a day overall and
  discovered a strange but apparent ignorance of final users that 
  the gcc team has. We will have to wait until the smoke clears and
  personal ambitions settle down.

  Finally, Chris, I appreciate your efforts to interpret emails to
  the two parties, but I can only stand by what I wrote ----
  I am pretty sure that PCs dominate general purpose computers,
  and that, independently, RedHat is dominating Linux installations --
  I saw this published ;-)  (I think you slightly misquoted me on this)

							Igor
-- 
  Igor Markov  office: (310) 206-0179   
  http://vlsicad.cs.ucla.edu/~imarkov

Re: FYI

[Christopher C Chimelis]

On Wed, 4 Aug 1999, Igor Markov wrote:
> 
>   I mailed to Michael Johnson of RedHat sometime ago re: the RPMs
>   for gcc and also contacted (many hrs ago) a guy who builds new RPMs
>   daily and announces them on a redhat mailing list.
> 
>   My point was that it would have been a prudent measure for the 
>   egcs group and cygnus support to establish such contacts earlier...
>   apparently you are of a difft opinion; oh well...
> 
>   It's probably even less effort than typing replies to my emails ;)

While I'm not a member of the egcs/gcc group, I can understand both sides
of this issue.  Igor, what they're trying to convey is that, because of
the sheer number of configurations and platforms supported by GCC, it
would be nearly impossible to keep a list of responsible parties for each
(partially because of time and partially because of turnover at each
respective company/organisation).  I can definitely understand your point
about ensuring that quality binary packages are generated from the gcc
group's work, but at the same time, they have enough work to do without
having to call and/or write everyone on a list regarding their releases.

On another note, to claim that Linux (and more specifically ix86 RedHat 
Linux) is the dominant OS obviously is not only irrelevant, but is also
incorrect.  My workplace, for example, uses both Alpha and i386 machines
running Debian Linux.  To me, Debian is the most obvious and dominant OS
of choice, but install-base does not necessarily dictate what the gcc
group should and shouldn't look after.  There are certainly MANY different
people using a variety of platforms that probably use and rely on GCC far
more than either of us do.  Does the fact that they use Solaris make them
any further down the list just because Solaris isn't as widely installed
as RedHat Linux?

Lastly, consider this: being a Debian developer who's thoroughly familiar
with RedHat's distribution, I've found that all RH releases rely solely on
the compiler distributed with them and do NOT *require* that a newer
version be installed.  Basically, if you want to ensure the quality of the
package, wait for RedHat's next release (which will most likely include
gcc 2.95).  On the other hand, using third-party builds of packages is
always risky.  I've watched RedHat's contrib directory over the years and
have been frightened at times at how poor the quality of some of the
packages there really is.

A solution:  write to one of the RedHat lists and ask if anyone has a
working gcc 2.95 RPM set finished and working.  If you get numerous
responces from people (all using the same set on configurations similar to
yours), then try the ones that they use and you will most likely get
better results than you have thusfar.

Good luck...
C

PS. I recently built the Debian .deb binary packages for Debian Alpha, so
let me assure you that there are MANY MANY variables that have to be
considered by the packager.  ALOT can go wrong (and in this case probably
has).

Re: FYI

[Christopher C Chimelis]

On Wed, 4 Aug 1999, Igor Markov wrote:

>   hmmm... I have been working with SunPro CC as a C++ compiler
>   for years because g++ could not compile C++ code that I wrote.
>   MSVC++ is another problem our lab supports.

Hehehe..yes, MSVC++ can be a difficult animal itself :-)

>   Now, with the new release of gcc, we planned to maintain the code
>   with g++ in addition to those two. I spent half a day overall and
>   discovered a strange but apparent ignorance of final users that 
>   the gcc team has. We will have to wait until the smoke clears and
>   personal ambitions settle down.

I can understand this....

>   Finally, Chris, I appreciate your efforts to interpret emails to
>   the two parties, but I can only stand by what I wrote ----
>   I am pretty sure that PCs dominate general purpose computers,
>   and that, independently, RedHat is dominating Linux installations --
>   I saw this published ;-)  (I think you slightly misquoted me on this)

I probably did :-) At any rate, the one thing that I think RedHat
consistantly overlooks is binary package dependencies (which Debian has,
believe me, this is not to toot our horn, just an example).  I think alot
of the misbuilt RPMs that I've run into relate to this.  In this case, I'm
pretty sure that ignorance of that issue, coupled with lack of general
knowledge on the packager's part (hence the ownership issues) and also
lack of general libtool knowledge (argh) probably defeated that set of
RPMs.  I would strongly recommend building it from source for two reasons:
ensuring that nothing was "added" to the RPMs in question and also so that
you can tailor the installation to your particular systems.  I have a more
than rudimentary understanding of gcc and the RPM format, but wouldn't
even attempt making a set of RPMs unless I was POSITIVE that I could make
them as portable as possible (obviously something overlooked by the
packager of the RPMs in contrib).

At any rate, I'll bow out of this discussion again :-)  I understand both
sides, but I would tend to agree with the "build it from the source"
advice on the list (I know I usually do, having an EV56 Alpha).

C

Re: FYI

[Igor Markov]

  hmmm... I have been working with SunPro CC as a C++ compiler
  for years because g++ could not compile C++ code that I wrote.
  MSVC++ is another problem our lab supports.

  Now, with the new release of gcc, we planned to maintain the code
  with g++ in addition to those two. I spent half a day overall and
  discovered a strange but apparent ignorance of final users that 
  the gcc team has. We will have to wait until the smoke clears and
  personal ambitions settle down.

  Finally, Chris, I appreciate your efforts to interpret emails to
  the two parties, but I can only stand by what I wrote ----
  I am pretty sure that PCs dominate general purpose computers,
  and that, independently, RedHat is dominating Linux installations --
  I saw this published ;-)  (I think you slightly misquoted me on this)

							Igor
-- 
  Igor Markov  office: (310) 206-0179   
  http://vlsicad.cs.ucla.edu/~imarkov

Re: FYI

[Christopher C Chimelis]

On Wed, 4 Aug 1999, Igor Markov wrote:
> 
>   I mailed to Michael Johnson of RedHat sometime ago re: the RPMs
>   for gcc and also contacted (many hrs ago) a guy who builds new RPMs
>   daily and announces them on a redhat mailing list.
> 
>   My point was that it would have been a prudent measure for the 
>   egcs group and cygnus support to establish such contacts earlier...
>   apparently you are of a difft opinion; oh well...
> 
>   It's probably even less effort than typing replies to my emails ;)

While I'm not a member of the egcs/gcc group, I can understand both sides
of this issue.  Igor, what they're trying to convey is that, because of
the sheer number of configurations and platforms supported by GCC, it
would be nearly impossible to keep a list of responsible parties for each
(partially because of time and partially because of turnover at each
respective company/organisation).  I can definitely understand your point
about ensuring that quality binary packages are generated from the gcc
group's work, but at the same time, they have enough work to do without
having to call and/or write everyone on a list regarding their releases.

On another note, to claim that Linux (and more specifically ix86 RedHat 
Linux) is the dominant OS obviously is not only irrelevant, but is also
incorrect.  My workplace, for example, uses both Alpha and i386 machines
running Debian Linux.  To me, Debian is the most obvious and dominant OS
of choice, but install-base does not necessarily dictate what the gcc
group should and shouldn't look after.  There are certainly MANY different
people using a variety of platforms that probably use and rely on GCC far
more than either of us do.  Does the fact that they use Solaris make them
any further down the list just because Solaris isn't as widely installed
as RedHat Linux?

Lastly, consider this: being a Debian developer who's thoroughly familiar
with RedHat's distribution, I've found that all RH releases rely solely on
the compiler distributed with them and do NOT *require* that a newer
version be installed.  Basically, if you want to ensure the quality of the
package, wait for RedHat's next release (which will most likely include
gcc 2.95).  On the other hand, using third-party builds of packages is
always risky.  I've watched RedHat's contrib directory over the years and
have been frightened at times at how poor the quality of some of the
packages there really is.

A solution:  write to one of the RedHat lists and ask if anyone has a
working gcc 2.95 RPM set finished and working.  If you get numerous
responces from people (all using the same set on configurations similar to
yours), then try the ones that they use and you will most likely get
better results than you have thusfar.

Good luck...
C

PS. I recently built the Debian .deb binary packages for Debian Alpha, so
let me assure you that there are MANY MANY variables that have to be
considered by the packager.  ALOT can go wrong (and in this case probably
has).

FYI

[Igor Markov]

  I mailed to Michael Johnson of RedHat sometime ago re: the RPMs
  for gcc and also contacted (many hrs ago) a guy who builds new RPMs
  daily and announces them on a redhat mailing list.

  My point was that it would have been a prudent measure for the 
  egcs group and cygnus support to establish such contacts earlier...
  apparently you are of a difft opinion; oh well...

  It's probably even less effort than typing replies to my emails ;)

								Igor
-- 
  Igor Markov  office: (310) 206-0179   
  http://vlsicad.cs.ucla.edu/~imarkov