Re: Illegal instruction (core dumped) on i586

Re: Illegal instruction (core dumped) on i586

[John Wehle]

> somehow, I don't see the explanations making sense...
> 
> Joe is essentially saying "use at your own risk"... 
>    that's not very helpful

It's hard to troubleshoot a product produced by a third party.
The best people to supply support for that product is those
people who made it.  The product produced by the gcc maintainers
is a source code release and I'm sure that they would be
interest in problems building their product on RedHat.

> It is certainly up to gcc maintainers to know what's new
> in libstc++-2.95 and what problems this may cause. That's
> the help I am trying to get here.

I'm sure that they do know what's new in libstc++-2.95, unfortunately
this isn't what you are asking about.  You are asking about problems
with a specific binary produced by a third party.  It's true that the
third party may have build the binary from gcc source code, however
there's a lot of variables outside of gcc maintainers control which
effect whether the binary in question will be useful for you.  Presumably
these variables are in the control of whoever built the binary.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------

Re: Illegal instruction (core dumped) on i586

[Igor Markov]

  John,

    thanks... what you are saying makes sense, but my
  main suggestion was that egcs maintainers consider
  ensuring the availability of good RPMs. This may 
  include contacting someone who can pack RPMs, or
  learning the RPM tricks or... talking to RedHat,
  whatever. Please do not consider this as "making
  binaries for every trashy system", but rather
  "ensuring the utility to major customers".
  I don't suppose many windows applications depend
  on gcc and libs, neither on Solaris or HP-UX.
  gcc is the default compiler on Linux. Things 
  are very difft here.

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

Re: Illegal instruction (core dumped) on i586

[Benjamin Scherrey]

Igor Markov wrote:
> 
>   John,
> 
>     thanks... what you are saying makes sense, but my
>   main suggestion was that egcs maintainers consider
>   ensuring the availability of good RPMs. This may
>   include contacting someone who can pack RPMs, or
>   learning the RPM tricks or... talking to RedHat,
>   whatever. Please do not consider this as "making
>   binaries for every trashy system", but rather
>   "ensuring the utility to major customers".

	Igor... "major customers" write checks.

	Ben Scherrey

Re: Illegal instruction (core dumped) on i586

[Benjamin Scherrey]

Igor Markov wrote:
> 
>   John,
> 
>     thanks... what you are saying makes sense, but my
>   main suggestion was that egcs maintainers consider
>   ensuring the availability of good RPMs. This may
>   include contacting someone who can pack RPMs, or
>   learning the RPM tricks or... talking to RedHat,
>   whatever. Please do not consider this as "making
>   binaries for every trashy system", but rather
>   "ensuring the utility to major customers".

	Igor... "major customers" write checks.

	Ben Scherrey

Re: Illegal instruction (core dumped) on i586

[Steven W Orr]

I'm inclined to agree on this one. As an example, fetchmail is delivered
as a .tar.gz file as well as a src.rpm. Lots of software is now coming
that way. When I install *anything* I always look for an rpm to install
from. *If* the tar.gz file is properly set up, i.e., if configure really
works 100% correctly, then the spec file for the rpm, by definition,
becomes trivial. I'm not going to go over the pros and cons of rpm vs. tgz
but I think it's a safe bet that anyone who doesn't use rpm is running on
a system that's just not rpm based. If you have it you use it without
question.

Is there anything else I can say to help stimulate the production of gcc
in both forms?

-- 
----------Time flies like the wind. Fruit flies like a banana.----------------
--------Stranger things have happened but none stranger than this.-------------
Steven W. Orr      steveo@world.std.com     <site of former bang addr:-)>
---------------"Listen to me! We are all individuals."-------------------------

On Wed, 4 Aug 1999, Igor Markov wrote:

=>
=>  John,
=>
=>    thanks... what you are saying makes sense, but my
=>  main suggestion was that egcs maintainers consider
=>  ensuring the availability of good RPMs. This may 
=>  include contacting someone who can pack RPMs, or
=>  learning the RPM tricks or... talking to RedHat,
=>  whatever. Please do not consider this as "making
=>  binaries for every trashy system", but rather
=>  "ensuring the utility to major customers".
=>  I don't suppose many windows applications depend
=>  on gcc and libs, neither on Solaris or HP-UX.
=>  gcc is the default compiler on Linux. Things 
=>  are very difft here.
=>
=>						Igor
=>

Re: Illegal instruction (core dumped) on i586

[Joe Buck]

> I'm inclined to agree on this one. As an example, fetchmail is delivered
> as a .tar.gz file as well as a src.rpm.

fetchmail is a completely independent program.  Installing fetchmail
won't change the behavior of other programs, and possibly make them
stop working.  Installing a new gcc package with a binary-incompatible
C++ library is another matter, one best left to the folks who put out
the distribution.

> Is there anything else I can say to help stimulate the production of gcc
> in both forms?

Even if we wanted to do it, there's no one that we can order to do the job
(the release manager and principal developers have their hands full and,
to the extent that they have free time, would prefer to improve the
compiler to dealing with packaging issues).  It would need to be done by a
skilled, careful volunteer who would not announce the result until he/she
had conducted thorough testing.  libstdc++/libc collisions are a frequent
problem on Linux, and this has to be managed carefully when doing binary
distributions.

Even then, the RPM should not install the new compiler in /usr/bin,
wiping out the system compiler.  For one thing, people would no longer
be able to build Linux kernels without manual intervention (as one
must specify -fno-strict-aliasing to build the kernel correctly).

Re: Illegal instruction (core dumped) on i586

[craig]

I agree with all of the sentiment about the GCC team not having
producing RPM's as one of its functions.

I'd like to add that my impression is that not just GCC, but GNU
generally, could benefit the community by looking over the various
package-management systems (RPMs, and doesn't Debian have one?) and
figuring out, at least, how best to architect, design, and implement
the relevant bits of GNU products so GNU maintainers, as well as
packagers, have an easier life producing robust, portable products.

        tq vm, (burley)

Re: Illegal instruction (core dumped) on i586

[Daniel Jacobowitz]

On Thu, Aug 05, 1999 at 03:03:14PM -0000, craig@jcb-sc.com wrote:
> I agree with all of the sentiment about the GCC team not having
> producing RPM's as one of its functions.
> 
> I'd like to add that my impression is that not just GCC, but GNU
> generally, could benefit the community by looking over the various
> package-management systems (RPMs, and doesn't Debian have one?) and
> figuring out, at least, how best to architect, design, and implement
> the relevant bits of GNU products so GNU maintainers, as well as
> packagers, have an easier life producing robust, portable products.

And as one of the people who makes the Debian packages (yes, we have
one), I can say that GCC has gone a long way down that road already. 
While the packaging is somewhat complex, it's not at all as bad as I
would have expected from a project of this size.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

Re: Illegal instruction (core dumped) on i586

[Daniel Jacobowitz]

On Thu, Aug 05, 1999 at 03:03:14PM -0000, craig@jcb-sc.com wrote:
> I agree with all of the sentiment about the GCC team not having
> producing RPM's as one of its functions.
> 
> I'd like to add that my impression is that not just GCC, but GNU
> generally, could benefit the community by looking over the various
> package-management systems (RPMs, and doesn't Debian have one?) and
> figuring out, at least, how best to architect, design, and implement
> the relevant bits of GNU products so GNU maintainers, as well as
> packagers, have an easier life producing robust, portable products.

And as one of the people who makes the Debian packages (yes, we have
one), I can say that GCC has gone a long way down that road already. 
While the packaging is somewhat complex, it's not at all as bad as I
would have expected from a project of this size.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

Re: Illegal instruction (core dumped) on i586

[craig]

I agree with all of the sentiment about the GCC team not having
producing RPM's as one of its functions.

I'd like to add that my impression is that not just GCC, but GNU
generally, could benefit the community by looking over the various
package-management systems (RPMs, and doesn't Debian have one?) and
figuring out, at least, how best to architect, design, and implement
the relevant bits of GNU products so GNU maintainers, as well as
packagers, have an easier life producing robust, portable products.

        tq vm, (burley)

a more constructive discussion ;-)

[Igor Markov]

> > Is there anything else I can say to help stimulate the production of gcc
> > in both forms?
> 
> Even if we wanted to do it, there's no one that we can order to do the job
> (the release manager and principal developers have their hands full and,
> to the extent that they have free time, would prefer to improve the
> compiler to dealing with packaging issues).  It would need to be done by a
> skilled, careful volunteer who would not announce the result until he/she
> had conducted thorough testing.  libstdc++/libc collisions are a frequent
> problem on Linux, and this has to be managed carefully when doing binary
> distributions.
> 
> Even then, the RPM should not install the new compiler in /usr/bin,
> wiping out the system compiler.  For one thing, people would no longer
> be able to build Linux kernels without manual intervention (as one
> must specify -fno-strict-aliasing to build the kernel correctly).

   Joe, great words.... esp.,

> Installing a new gcc package with a binary-incompatible
> C++ library is another matter, one best left to the folks who put out
> the distribution.

   interestingly, my suggestion does not conflict with this at all.
   Given the feedback that I got from this list so far, I would boil
   it to the following:
    
     1) create a mailing list "gcc-binaries"
     2) maintain a page with "binary distributions"
     3) maintain "binary packaging test status" on a separate page,
        i.e., a list of reported successful/failed installation
        on various systems; 
     4) keep a list of volunteer "contacts" for various platforms
        who are willing to assume some limited responsibily and
        take care of bug reports

   in the simplest for, the status page will be empty... as long as
   someone reports success installing smth on some system and a link
   to the binaries (+ a description of the operation), we can add a line
   to the status page.

   If that sounds good, I would be willing to contribute some of my time
   to this activity. OTOH, I am not sure if I am the best candidate for
   this as I don't have much experience hacking various systems (never had
   a non-RH Linux or BSD here, never loged in to an HP or an SGI system,
   never used gcc on Windows and know little about DLLs, registry etc).
   I would simply like to show "a good faith effort" here and motivate
   others and hope that some common sense and the ability to put out Web
   pages will be useful here (after all, no one can be expected to actually
   have access to all the systems, so we will have to rely on email and tally
   successes/failures).

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

Re: a more constructive discussion ;-)

[Gerald Pfeifer]

On Thu, 5 Aug 1999, Igor Markov wrote:
>    interestingly, my suggestion does not conflict with this at all.
>    Given the feedback that I got from this list so far, I would boil
>    it to the following:
>     
>      1) create a mailing list "gcc-binaries"
>      2) maintain a page with "binary distributions"
>      3) maintain "binary packaging test status" on a separate page,
>         i.e., a list of reported successful/failed installation
>         on various systems; 
>      4) keep a list of volunteer "contacts" for various platforms
>         who are willing to assume some limited responsibily and
>         take care of bug reports
> [...]
>    If that sounds good, I would be willing to contribute some of my time
>    to this activity.
> 
>      comments?

Most/all of us have rather long queues of GCC work these days, for
example, right now one port (FreeBSD) does not even bootstrap because
none has had sufficient time to review a patch that fixes the problem.

However, if you are going to set up a web page/mailing list covering that
information, I will be happy to provide a link from our site.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: a more constructive discussion ;-)

[Gerald Pfeifer]

On Thu, 5 Aug 1999, Igor Markov wrote:
>    interestingly, my suggestion does not conflict with this at all.
>    Given the feedback that I got from this list so far, I would boil
>    it to the following:
>     
>      1) create a mailing list "gcc-binaries"
>      2) maintain a page with "binary distributions"
>      3) maintain "binary packaging test status" on a separate page,
>         i.e., a list of reported successful/failed installation
>         on various systems; 
>      4) keep a list of volunteer "contacts" for various platforms
>         who are willing to assume some limited responsibily and
>         take care of bug reports
> [...]
>    If that sounds good, I would be willing to contribute some of my time
>    to this activity.
> 
>      comments?

Most/all of us have rather long queues of GCC work these days, for
example, right now one port (FreeBSD) does not even bootstrap because
none has had sufficient time to review a patch that fixes the problem.

However, if you are going to set up a web page/mailing list covering that
information, I will be happy to provide a link from our site.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

a more constructive discussion ;-)

[Igor Markov]

> > Is there anything else I can say to help stimulate the production of gcc
> > in both forms?
> 
> Even if we wanted to do it, there's no one that we can order to do the job
> (the release manager and principal developers have their hands full and,
> to the extent that they have free time, would prefer to improve the
> compiler to dealing with packaging issues).  It would need to be done by a
> skilled, careful volunteer who would not announce the result until he/she
> had conducted thorough testing.  libstdc++/libc collisions are a frequent
> problem on Linux, and this has to be managed carefully when doing binary
> distributions.
> 
> Even then, the RPM should not install the new compiler in /usr/bin,
> wiping out the system compiler.  For one thing, people would no longer
> be able to build Linux kernels without manual intervention (as one
> must specify -fno-strict-aliasing to build the kernel correctly).

   Joe, great words.... esp.,

> Installing a new gcc package with a binary-incompatible
> C++ library is another matter, one best left to the folks who put out
> the distribution.

   interestingly, my suggestion does not conflict with this at all.
   Given the feedback that I got from this list so far, I would boil
   it to the following:
    
     1) create a mailing list "gcc-binaries"
     2) maintain a page with "binary distributions"
     3) maintain "binary packaging test status" on a separate page,
        i.e., a list of reported successful/failed installation
        on various systems; 
     4) keep a list of volunteer "contacts" for various platforms
        who are willing to assume some limited responsibily and
        take care of bug reports

   in the simplest for, the status page will be empty... as long as
   someone reports success installing smth on some system and a link
   to the binaries (+ a description of the operation), we can add a line
   to the status page.

   If that sounds good, I would be willing to contribute some of my time
   to this activity. OTOH, I am not sure if I am the best candidate for
   this as I don't have much experience hacking various systems (never had
   a non-RH Linux or BSD here, never loged in to an HP or an SGI system,
   never used gcc on Windows and know little about DLLs, registry etc).
   I would simply like to show "a good faith effort" here and motivate
   others and hope that some common sense and the ability to put out Web
   pages will be useful here (after all, no one can be expected to actually
   have access to all the systems, so we will have to rely on email and tally
   successes/failures).

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

Re: Illegal instruction (core dumped) on i586

[Joe Buck]

> I'm inclined to agree on this one. As an example, fetchmail is delivered
> as a .tar.gz file as well as a src.rpm.

fetchmail is a completely independent program.  Installing fetchmail
won't change the behavior of other programs, and possibly make them
stop working.  Installing a new gcc package with a binary-incompatible
C++ library is another matter, one best left to the folks who put out
the distribution.

> Is there anything else I can say to help stimulate the production of gcc
> in both forms?

Even if we wanted to do it, there's no one that we can order to do the job
(the release manager and principal developers have their hands full and,
to the extent that they have free time, would prefer to improve the
compiler to dealing with packaging issues).  It would need to be done by a
skilled, careful volunteer who would not announce the result until he/she
had conducted thorough testing.  libstdc++/libc collisions are a frequent
problem on Linux, and this has to be managed carefully when doing binary
distributions.

Even then, the RPM should not install the new compiler in /usr/bin,
wiping out the system compiler.  For one thing, people would no longer
be able to build Linux kernels without manual intervention (as one
must specify -fno-strict-aliasing to build the kernel correctly).

Re: Illegal instruction (core dumped) on i586

[Steven W Orr]

I'm inclined to agree on this one. As an example, fetchmail is delivered
as a .tar.gz file as well as a src.rpm. Lots of software is now coming
that way. When I install *anything* I always look for an rpm to install
from. *If* the tar.gz file is properly set up, i.e., if configure really
works 100% correctly, then the spec file for the rpm, by definition,
becomes trivial. I'm not going to go over the pros and cons of rpm vs. tgz
but I think it's a safe bet that anyone who doesn't use rpm is running on
a system that's just not rpm based. If you have it you use it without
question.

Is there anything else I can say to help stimulate the production of gcc
in both forms?

-- 
----------Time flies like the wind. Fruit flies like a banana.----------------
--------Stranger things have happened but none stranger than this.-------------
Steven W. Orr      steveo@world.std.com     <site of former bang addr:-)>
---------------"Listen to me! We are all individuals."-------------------------

On Wed, 4 Aug 1999, Igor Markov wrote:

=>
=>  John,
=>
=>    thanks... what you are saying makes sense, but my
=>  main suggestion was that egcs maintainers consider
=>  ensuring the availability of good RPMs. This may 
=>  include contacting someone who can pack RPMs, or
=>  learning the RPM tricks or... talking to RedHat,
=>  whatever. Please do not consider this as "making
=>  binaries for every trashy system", but rather
=>  "ensuring the utility to major customers".
=>  I don't suppose many windows applications depend
=>  on gcc and libs, neither on Solaris or HP-UX.
=>  gcc is the default compiler on Linux. Things 
=>  are very difft here.
=>
=>						Igor
=>

Re: Illegal instruction (core dumped) on i586

[Philipp Thomas]

On Wed, 04 Aug 1999 15:25:36 -0700, Igor Markov <imarkov@cs.ucla.edu> wrote:

>"ensuring the utility to major customers"

Amazing, you still don't seem to get it.

Pardon, Customers ? Did we charge you for downloading ? So stop talking of
customers. Yes, Linux is an important platform for the gcc team and much
effort has gone into making gcc work on that platform, provided that it is
being built by someone who knows how to do it.

This is free software, created by volunteers. So, as I already wrote in
another mail, get a clue or move to an OS where you pay for what you get and
thus have a right to demand anything.



Philipp

-- 
Nothing would please me more than being able to hire ten programmers
and deluge the hobby market with good software.
                                            -- Bill Gates, 1976

Re: Illegal instruction (core dumped) on i586

[Philipp Thomas]

On Wed, 04 Aug 1999 15:25:36 -0700, Igor Markov <imarkov@cs.ucla.edu> wrote:

>"ensuring the utility to major customers"

Amazing, you still don't seem to get it.

Pardon, Customers ? Did we charge you for downloading ? So stop talking of
customers. Yes, Linux is an important platform for the gcc team and much
effort has gone into making gcc work on that platform, provided that it is
being built by someone who knows how to do it.

This is free software, created by volunteers. So, as I already wrote in
another mail, get a clue or move to an OS where you pay for what you get and
thus have a right to demand anything.



Philipp

-- 
Nothing would please me more than being able to hire ten programmers
and deluge the hobby market with good software.
                                            -- Bill Gates, 1976

Re: Illegal instruction (core dumped) on i586

[Igor Markov]

  John,

    thanks... what you are saying makes sense, but my
  main suggestion was that egcs maintainers consider
  ensuring the availability of good RPMs. This may 
  include contacting someone who can pack RPMs, or
  learning the RPM tricks or... talking to RedHat,
  whatever. Please do not consider this as "making
  binaries for every trashy system", but rather
  "ensuring the utility to major customers".
  I don't suppose many windows applications depend
  on gcc and libs, neither on Solaris or HP-UX.
  gcc is the default compiler on Linux. Things 
  are very difft here.

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

Re: Illegal instruction (core dumped) on i586

[John Wehle]

> somehow, I don't see the explanations making sense...
> 
> Joe is essentially saying "use at your own risk"... 
>    that's not very helpful

It's hard to troubleshoot a product produced by a third party.
The best people to supply support for that product is those
people who made it.  The product produced by the gcc maintainers
is a source code release and I'm sure that they would be
interest in problems building their product on RedHat.

> It is certainly up to gcc maintainers to know what's new
> in libstc++-2.95 and what problems this may cause. That's
> the help I am trying to get here.

I'm sure that they do know what's new in libstc++-2.95, unfortunately
this isn't what you are asking about.  You are asking about problems
with a specific binary produced by a third party.  It's true that the
third party may have build the binary from gcc source code, however
there's a lot of variables outside of gcc maintainers control which
effect whether the binary in question will be useful for you.  Presumably
these variables are in the control of whoever built the binary.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------