This is the mail archive of the
mailing list for the Cygwin project.
RE: Mysterious gdb behavior.
- From: "Paul Derbyshire" <derbyshire at globalserve dot net>
- To: cygwin at cygwin dot com
- Date: Fri, 2 Aug 2002 23:42:13 -0400
- Subject: RE: Mysterious gdb behavior.
- Reply-to: derbyshire at globalserve dot net
On 2 Aug 2002 at 9:55, Demmer, Thomas wrote:
> I think you all need to chill out for a while.
Yes, they do.
> Paul, what's wrong with just trying in a bash
> $ type cygcheck
> cygcheck is /usr/bin/cygcheck
That it would never occur to me to do so without first finding and
downloading cygcheck? I was waiting for someone to give a URL.
> Also, what is fundamentally wrong with
> $ cp hw.* /tmp
> $ cd /tmp
> $ gdb hw
Someone suggested something of the sort, and I tried it and posted
the results. I don't recall seeing it suggested prior to tonight's
batch of mail.
> Also, on getting a hint about cygcheck you mails would be much better
> reacted on if you just
> 1) looked if it may be already installed
I don't recall installing it. If it came packaged with something else
I might already have it. Of course, it would have been helpful if
someone gave a download link.
I can check to see if it got onto my system piggybacked on another
module with "which cygcheck" I suppose...hmm, apparently I have a
/usr/bin/cygcheck, I guess it did. Still why would it occur to me
that it might already be installed? It's obviously not a stock unix
command like ls or grep...
> 2) send the output to the list
> instead of ranting around "what the fuck is cygcheck?"
Being told to use something I'm not even sure I have and definitely
don't know where to get tends to provoke that kind of reaction. Of
course, the question will be phrased more politely if it's not the
And before anyone suggests that I should know everything that's
installed on my system, I don't have the time or the inclination to
read a listing of /bin and /usr/bin before making each posting. I'd
be surprised if anybody does...
As for finding what isn't installed, if it's in a cygwin package
gimme the package name so I don't waste hours downloading everything
with setup until the binary shows up; and if it's obtained separately
gimme a URL, or at least tell me about an ftp searcher that actually
is marginally useful.
> Another interesting fact:
> For the first time you gave the commandline how you built the executable.
> I am not sure if gcc does not care about option order (it does for
> one thing *I* would
> try is
> gcc -g -o hw.exe hw.c
> (Note different order and omission of optimizer).
Funky. I've never seen anyone use a commandline like this for gcc.
I've been building things with gcc foo.c -o foo.exe -lbar -lbaz -g -
O2 and gcc -c foo.c -g -O2 and such for years without any problem.
The only case where order matters is that object files should appear
before object files they depend upon, unless you're building a
library, and libraries should appear before libraries they depend
Also, gcc's debugging information is better if the optimizer is *on*,
different from many C compilers' behavior. I assume you did not know
this. Of course the quality of debugging information doesn't affect
the ability to even run the blamed thing in the debugger...
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html