Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <3BAA0DE9.7EC296EE@syntrex.com> Date: Thu, 20 Sep 2001 17:40:25 +0200 From: Pavel Tsekov Organization: Syntrex Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: WTF?! References: <20010918114701 DOT D510 AT redhat DOT com> <20010920013727 DOT A5780 AT mamet DOT westofhouse DOT net> <20010920112518 DOT A28377 AT redhat DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Christopher Faylor wrote: > > On Thu, Sep 20, 2001 at 01:37:27AM -0400, Christopher Currie wrote: > >Sorry for the cross-posting, but this regards a bug in libiberty and I > >don't know whether gcc or binutils has ownership of it. > > If you are going to take it upon yourself to take a cygwin problem into > other mailing lists, you really should check out the CVS sources to see > if this has actually been solved or not. > > >On Tue, Sep 18, 2001 at 11:47:01AM -0400, Christopher Faylor wrote: > >> It is just C source code we're talking about, right? You have an editor? > >> Look at the place where the errors are coming from and make an > >> educated guess about fixing it. > >> > >> What is the worse that can happen? If you screw up do you think that > >> this will cause gcc to subtly miscompile your code so that all of the > >> add instructions are turned into sub instructions or something? That's > >> not going to happen. > >> > >> You are all programmers right? Inspect the code. Invest five minutes > >> worth of analysis into the problem. > >> > >> If this is too tough for you, try removing the offending file from the > >> makefile or building from CVS sources. > >> > >> I can't believe that there are three messages on this subject from people > >> who are apparently programmers without one suggested fix. > > > > > >Probably because most of them are busy trying use the tools to do the > >work they get paid to do, rather than spend the time fixing the tools. > >Since backing out to the previous version allows them to do that, they've > >done what's expected of them and logged a bug report that (IMHO) helps > >a maintainer (who, I would think, either has volunteered or is paid to > >do such things) track down what might be causing the problem. > > > > Some points: > > 1) No one is paid to support this code. > > 2) No one has volunteered to support other people's efforts to compile the > code. > > 3) No one was asking for a definitive fix. I was basically commenting on > how strange it was that people who are supposed to be programmers were > stalled for days over a problem that could have been solved by an #ifdef. > The problem has been fixed definitively in sources.redhat.com CVS sources > for weeks. However, that fix won't magically propagate to older source > tar balls. So, a brain-dead simple fix to strerror.c is required. > > Either that or you can use the solution THAT I ALREADY SUGGESTED. > > 4) If someone is building the code on their own rather than using the binaries > that *I did* volunteer to provide then it is either part of their job or > they have some other reason for doing it. It's not part of my job in > any way to track down their problems for them. I could build the programs > just fine when I released them. If that changes over time, I'm not going > to make a new release just to satisfy people who want to build things on > their own. If someone needs to do that then they really should know what > they are doing. Either that or they should pay someone to support them. > Or, they could try to use the *latest* versions of the sources where any > problems would be solved. > > 5) Even if we were to buy into your theory that I have either volunteered > to help you build the tools or your even more inane theory that I am > actually being *paid* to help people for free; merely reporting a problem > with no more analysis than a cut and paste of an error message is hardly > a way to help me out. Even if it was a vague help, the majority of this > thread was comprised of "I am stalled too! I need a fix!" messages which > conveyed no useful information. > > I haven't looked at your patch. You seem competent so I assume that it > solves your problem. > > I also assume that a patch won't help most of the original posters who > were complaining in the cygwin mailing list since it will require them > to learn about both patch and autoconf. However, maybe there are some > other previously silent but competent people like you who were also > silently fuming over the injustice of not being able to compile their > own version of the tools and maybe they will be able to use the solution > that you provided. > > Or, you could always just remove strerror from the Makefile like I > originally suggested... > > cgf > Cristopher, why dont just you stop reading those posts which actually dont tend to be good enough for you ? I think if point 1 applies to you then you are not being paid to read the mailing lists too - are you ? So "silly" mails are easily to be recognized - you can just pass them by. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/