This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Mysterious gdb behavior.


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 
umpteenth time.

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
> libraries), 
> 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 
upon.

Also, gcc's debugging information is better if the optimizer is *on*, 
which is 
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
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]