RE: cygwin bughunt (FAQ alert?)

RE: cygwin bughunt (FAQ alert?)

[Hughes, Bill]

Corinna Vinschen wrote:
> On Jan 21 11:18, Hughes, Bill wrote:
>> I don't think I'm putting this very well, but it may make the FAQ
>> easier if the standard advice is to load the snaphot and use that
>> for debugging, it removes a separate layer of potential problems in
>> building the dll. I suspect the people who would want a stripped
>> snapshot to be more capable of producing it than those would may
>> need to build one with debug info. 
> 
> IMHO you're looking from the wrong direction.  People capable
> of debugging
> the Cygwin DLL are usually also capable of building it.  I'm wondering
> how somebody should be able to debug an application at all,
> if this person
> stumbles over using the compiler tools.
Which is why I asked, I suspect I was hoping there was a way to help newbies
(like me in this respect) to generate useful reports in cases of suspected
bugs for the more knowledgeable to read.
Of course if there were such a way I would expect someone else to have
thought of it, and so it's probably impracticable.

Thanks for the reply,
Bill
-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.tigris.org

This e-mail transmission is strictly confidential and intended solely
for the person or organisation to whom it is addressed. It may contain
privileged and confidential information and if you are not the intended
recipient, you must not copy, distribute or take any action in reliance
on it. If you have received this email in error, please reply to the
sender as soon as possible and delete the message. Please note that we
are able to, and reserve the right to, monitor e-mail communications
passing through our network.

The views expressed in this email are not that of the company unless
specified within the message.

The inclusion of this footnote indicates that the mail message and any
attachments have been checked for the presence of known viruses.

If you have any comments regarding our policy please direct them to
postmaster@cox.co.uk
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Brian Dessent]

Joshua Daniel Franklin wrote:

> Fixed. By the way, does anyone know exactly what Devel packages are required
> to build Cygwin?  I used to just think "install everything" but now
> there's a lot of
> new X or GNOME related stuff. I know I've got more than I need
> installed, but I'm
> thinking that would be useful information for the FAQ and/or a README in CVS.
> 
> binutils
> gcc
> make
> gettext-devel
> ??

I was actually a little curious about this, so I did a little
experiment.  I sequestered away my normal Cygwin installation and
started with a fresh install.  Aside from the default "base" packages
that setup.exe intstalls out of the gate, I found that I only had to
actually select three packages in setup: gcc, make, and perl.  (and Perl
was required only for gendef it seems.)

After doing that I was able to build the Cygwin DLL from the source
package.  Additional things may be required to build from a CVS
checkout, I'm not sure.  And of course the dependencies of those
packages are required (i.e. gcc brings in w32api, binutils,
mingw-runtime, ...; perl brings in crypt, expat, ...) but from a user
standpoint if you're using setup those are apparently the only three
individual packages you need to select.

If you want an absolute list, here is my "cygcheck -c" for this test
environment, which was the result of "default install plus selecting
gcc, make, and perl":

Cygwin Package Information
Package              Version            Status
_update-info-dir     00231-1            OK
ash                  20040127-1         OK
base-files           3.2-1              OK
base-passwd          2.1-1              OK
bash                 2.05b-16           OK
binutils             20041229-1         OK
bzip2                1.0.2-6            OK
coreutils            5.2.1-5            OK
crypt                1.1-1              OK
cygutils             1.2.5-1            OK
cygwin               1.5.12-1           OK
cygwin-doc           1.4-1              OK
diffutils            2.8.7-1            OK
editrights           1.01-1             OK
expat                1.95.8-1           OK
findutils            20041227-1         OK
gawk                 3.1.4-3            OK
gcc                  3.3.3-3            OK
gcc-core             3.3.3-3            OK
gcc-g++              3.3.3-3            OK
gcc-mingw-core       20040810-1         OK
gcc-mingw-g++        20040810-1         OK
gdbm                 1.8.3-7            OK
grep                 2.5-1              OK
groff                1.18.1-2           OK
gzip                 1.3.5-1            OK
less                 381-1              OK
libbz2_1             1.0.2-6            OK
libcharset1          1.9.2-1            OK
libdb4.2             4.2.52-1           OK
libgdbm              1.8.0-5            OK
libgdbm-devel        1.8.3-7            OK
libgdbm3             1.8.3-3            OK
libgdbm4             1.8.3-7            OK
libiconv             1.9.2-1            OK
libiconv2            1.9.2-1            OK
libintl1             0.10.40-1          OK
libintl2             0.12.1-3           OK
libintl3             0.14.1-1           OK
libncurses5          5.2-1              OK
libncurses6          5.2-8              OK
libncurses7          5.3-4              OK
libncurses8          5.4-1              OK
libpcre              4.1-1              OK
libpcre0             4.5-1              OK
libpopt0             1.6.4-4            OK
libreadline4         4.1-2              OK
libreadline5         4.3-5              OK
libreadline6         5.0-1              OK
login                1.9-7              OK
make                 3.80-1             OK
man                  1.5o1-1            OK
mingw-runtime        3.7-1              OK
mktemp               1.5-3              OK
ncurses              5.4-1              OK
perl                 5.8.6-2            OK
readline             5.0-1              OK
sed                  4.1.2-1            OK
tar                  1.13.25-5          OK
termcap              20021106-2         OK
terminfo             5.4_20041009-1     OK
texinfo              4.7-2              OK
w32api               3.2-1              OK
which                1.6-1              OK
zlib                 1.2.2-1            OK

Brian


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Joshua Daniel Franklin]

On Wed, 26 Jan 2005 14:36:50 -0800, Joshua Daniel Franklin wrote:
> On Wed, 26 Jan 2005 14:29:29 +0100, David Dindorp wrote:
> > And the link in the FAQ is wrong:
> >
> > "How can I debug cygwin" (entry 105) says:
> >
> > "To build a debugging version of the Cygwin DLL,
> >  you will need to follow the instructions at
> >  http://cygwin.com/faq/faq_3.html#SEC102."
> >
> > The above should point to entry 104, not 102.
> 
> Sorry, I'll fix this.

Fixed. By the way, does anyone know exactly what Devel packages are required
to build Cygwin?  I used to just think "install everything" but now
there's a lot of
new X or GNOME related stuff. I know I've got more than I need
installed, but I'm
thinking that would be useful information for the FAQ and/or a README in CVS. 

binutils
gcc
make
gettext-devel
??

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Joshua Daniel Franklin]

On Wed, 26 Jan 2005 14:29:29 +0100, David Dindorp wrote:
> How about adding a line in the FAQ to the "how to build cygwin" (104)
> entry
> stating that the "configure ; make" mentioned does produce a Cygwin with
> all
> debugging symbols?
> 
> And the link in the FAQ is wrong:
> 
> "How can I debug cygwin" (entry 105) says:
> 
> "To build a debugging version of the Cygwin DLL,
>  you will need to follow the instructions at
>  http://cygwin.com/faq/faq_3.html#SEC102."
> 
> The above should point to entry 104, not 102.

Sorry, I'll fix this.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[David Dindorp]

Ack!
Apologies for the formatting.
The company I'm employed at uses Outlook (thereby MS-WORD) for e-mail.

Here's what I wanted to say:

The FAQ entry 105 links to entry 102 under "how to compile".
Shouldn't this point to 104 instead?



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[David Dindorp]

Igor Pechtchanski wrote:
>> Umm, that was my bad.  The thing is, "--enable-debugging" really
produces
>> a developer debug version, with extra tracing, etc.  If all you want
is a
>> version of DLL with all the symbols (i.e., unstripped), the regular
build
>> produces that as well.

Cristopher Faylor wrote:
> ...and now you get to repeat these facts endlessly as people find your
> words in the archives and assume that they need use this option
regardless
> of follow-on discussion or the FAQ.

How about adding a line in the FAQ to the "how to build cygwin" (104)
entry
stating that the "configure ; make" mentioned does produce a Cygwin with
all
debugging symbols?

And the link in the FAQ is wrong:

"How can I debug cygwin" (entry 105) says:

"To build a debugging version of the Cygwin DLL,
 you will need to follow the instructions at
 http://cygwin.com/faq/faq_3.html#SEC102."

The above should point to entry 104, not 102.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Christopher Faylor]

On Tue, Jan 25, 2005 at 04:07:18PM -0500, Igor Pechtchanski wrote:
>On Tue, 25 Jan 2005, David Dindorp wrote:
>
>> Cristopher Faylor wrote:
>> > Actually, we do.  We provide the source code.  It's easy to build.
>>
>> On your particular system which is tuned to do precisely this, maybe.
>> If it's as easy as you say, I'll spend some more time on it.
>>
>> > Have you even tried it?
>>
>> No.  For a couple of reasons.
>> [snip]
>> 3. I had no idea of the "--enable-debugging" option that creates a
>> debug version, or any of the other requirements for making the source
>> compile (I'm sure there exists some).
>
>Umm, that was my bad.  The thing is, "--enable-debugging" really produces
>a developer debug version, with extra tracing, etc.  If all you want is a
>version of DLL with all the symbols (i.e., unstripped), the regular build
>produces that as well.

...and now you get to repeat these facts endlessly as people find your
words in the archives and assume that they need use this option regardless
of follow-on discussion or the FAQ.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Igor Pechtchanski]

On Tue, 25 Jan 2005, David Dindorp wrote:

> Cristopher Faylor wrote:
> > Actually, we do.  We provide the source code.  It's easy to build.
>
> On your particular system which is tuned to do precisely this, maybe.
> If it's as easy as you say, I'll spend some more time on it.
>
> > Have you even tried it?
>
> No.  For a couple of reasons.
> [snip]
> 3. I had no idea of the "--enable-debugging" option that creates a
> debug version, or any of the other requirements for making the source
> compile (I'm sure there exists some).

Umm, that was my bad.  The thing is, "--enable-debugging" really produces
a developer debug version, with extra tracing, etc.  If all you want is a
version of DLL with all the symbols (i.e., unstripped), the regular build
produces that as well.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[David Dindorp]

Cristopher Faylor wrote:
> Actually, we do.  We provide the source code.  It's easy to build.

On your particular system which is tuned to do precisely this, maybe.

If it's as easy as you say, I'll spend some more time on it.


> Have you even tried it?

No.  For a couple of reasons.

1. Prior experience with compiling large open source projects have
shown me that it usually takes intimate knowledge of the source code
and what tools and operating system should be used in order to make
a good compile.

2. Other peoples posting suggested compiling Cygwin is not a walk in
the park.

3. I had no idea of the "--enable-debugging" option that creates a
debug version, or any of the other requirements for making the source
compile (I'm sure there exists some).

4. I hate to bug the list with stupid questions on how to compile
Cygwin, when all I really need is to retrieve more debug information
from a running system, not compile a new one.

5.  Probably more reasons.  Nobody cares, so I'm going to stop the
listing here :-).


I just tried a regular (non-debug) compile, compiling the freshest
source that comes with the stock 1.5.10, using GCC etc. from 1.5.10.
It stopped compiling with this error message:

/winsup/cygwin/errno.cc:154: error:
 external linkage required for symbol 'const char* const _sys_errlist[]'
 because of 'dllexport' attribute.

The cause for this particular compile error is probably some minor
technicality, but add up a dozen of these, and I will soon have spent a
month just trying to make myself a debug DLL to match my 1.5.10 :-(.

I've seen advice elsewhere to simply migrate through Cygwin versions
until I happen to bump into one that works with the application in
question.  With limited time on my hands (I can't devote a month to
finding out how to compile Cygwin proper), I think that that's maybe
the most viable solution so far?..

Otherwise I may put some more effort into the whole compilation thing.
There's another version of the source that comes with stock 1.5.10
which so far only complains about missing 'w32api'-something, so maybe
I'll have more luck with that.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Joshua Daniel Franklin]

> On Sat, Jan 22, 2005 at 03:42:15PM -0800, Joshua Daniel Franklin wrote:
> >Yep, I missed that. It's gone, but with the other FAQ additions it moved:
> >
> >http://cygwin.com/faq/faq0.html#SEC104

On Sat, 22 Jan 2005 18:46:41 -0500, Christopher Faylor wrote:
> This feels vaguely like I'm programming in Fortran again.
> 
> It would be nice (tm, (C), etc.) if there was some way to put permanent
> anchors in the FAQ so that we wouldn't have to rely on renumbered
> sections.
> 
> Isn't there any way to accomplish that?

Not that I know of with Texinfo, even the GNU Texinfo manual's HTML version 
uses numbered anchors:

http://gnu.hands.com/manual/texinfo-4.0/html_chapter/texinfo_4.html#SEC35

I could do it with DocBook's FAQ stuff, as in this example:

http://www.miwie.org/docbook-dsssl-faq.html#COLOUREDLINKS

I'd kinda like to get everything in DocBook anyway.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Christopher Faylor]

On Sat, Jan 22, 2005 at 03:42:15PM -0800, Joshua Daniel Franklin wrote:
>> On Sat, Jan 22, 2005 at 11:36:00AM -0800, Joshua Daniel Franklin wrote:
>> >To build a debugging version of the Cygwin DLL, you will need to follow
>> >the instructions at http://cygwin.com/faq/faq_3.html#SEC102, adding the
>> >`--enable-debugging' option to `../configure'. You can also contact the
>> >mailing list for pointers (a simple test case that demonstrates the bug
>> >is always welcome).
>
>On Sat, 22 Jan 2005 16:06:43 -0500, Christopher Faylor  wrote:
>
>> You must have missed my post where I said not to use the
>> --enable-debugging option.
>> 
>> Please remove the mention of the --enable-debugging option.  This should
>> only be done when you've been prompted to do so.  It's for developers,
>> not for normal users.
>
>Yep, I missed that. It's gone, but with the other FAQ additions it moved:
>
>http://cygwin.com/faq/faq0.html#SEC104

This feels vaguely like I'm programming in Fortran again.

It would be nice (tm, (C), etc.) if there was some way to put permanent
anchors in the FAQ so that we wouldn't have to rely on renumbered
sections.

Isn't there any way to accomplish that?

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Joshua Daniel Franklin]

> On Sat, Jan 22, 2005 at 11:36:00AM -0800, Joshua Daniel Franklin wrote:
> >To build a debugging version of the Cygwin DLL, you will need to follow
> >the instructions at http://cygwin.com/faq/faq_3.html#SEC102, adding the
> >`--enable-debugging' option to `../configure'. You can also contact the
> >mailing list for pointers (a simple test case that demonstrates the bug
> >is always welcome).

On Sat, 22 Jan 2005 16:06:43 -0500, Christopher Faylor  wrote:

> You must have missed my post where I said not to use the
> --enable-debugging option.
> 
> Please remove the mention of the --enable-debugging option.  This should
> only be done when you've been prompted to do so.  It's for developers,
> not for normal users.

Yep, I missed that. It's gone, but with the other FAQ additions it moved:

http://cygwin.com/faq/faq0.html#SEC104

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Christopher Faylor]

On Sat, Jan 22, 2005 at 11:36:00AM -0800, Joshua Daniel Franklin wrote:
>To build a debugging version of the Cygwin DLL, you will need to follow
>the instructions at http://cygwin.com/faq/faq_3.html#SEC102, adding the
>`--enable-debugging' option to `../configure'. You can also contact the
>mailing list for pointers (a simple test case that demonstrates the bug
>is always welcome).  

You must have missed my post where I said not to use the
--enable-debugging option.

Please remove the mention of the --enable-debugging option.  This should
only be done when you've been prompted to do so.  It's for developers,
not for normal users.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Joshua Daniel Franklin]

OK the three FAQs beginning at http://cygwin.com/faq/faq0.html#SEC102
now read:

How do I build Cygwin on my own?

First, you need to get the Cygwin source. Ideally, you should check
out what you need from CVS (http://cygwin.com/cvs.html). This is the
preferred method for acquiring the sources. Otherwise, you can install
the cygwin source package from the distribution.

If you are trying to duplicate a cygwin release then you should just
download the corresponding source package and use "tar xjf" to unpack
it. This will unpack the sources into a directory named cygwin-x.y.z-n,
where x.y.z-n correspond to the version numbering of the tar.bz2 package.

tar xjf cygwin-1.5.12-1-src.tar.bz2 
cd cygwin-1.5.12-1

You must build cygwin in a separate directory from the source, so create
something like a `build/' directory. You will also want to install to
a temporary location:

mkdir build 
mkdir /install 
cd build (../configure --prefix=/install -v; make) >& make.out 
make install > install.log 2>&1

Normally, this procedure ignore errors in building the
documentation. which requires the `docbook-xml', `docbook-xsl', and
`xmlto' packages. For more information on building the documentation,
see the README included in the cygwin-doc package.

To check a cygwin1.dll, run "make check" in the winsup/testsuite
directory. If that works, install everything except the dll (if you
can). Then, close down all cygwin programs (including bash windows,
inetd, etc.), save your old dll, and copy the new dll to the correct
place. Then start up a bash window, or run a cygwin program from the
Windows command prompt, and see what happens.

If you get the error "shared region is corrupted" it means that two
different versions of cygwin1.dll are running on your machine at the
same time. Remove all but one.  

I may have found a bug in Cygwin, how
can I debug it (the symbols in gdb look funny)?

Debugging symbols are stripped from distibuted Cygwin binaries, so any
symbols that you see in gdb are basically meaningless. It is also a
good idea to use the latest code in case the bug has been fixed, so we
recommend trying the latest snapshot from http://cygwin.com/snapshots/
or build the DLL from CVS.

To build a debugging version of the Cygwin DLL, you will need to follow
the instructions at http://cygwin.com/faq/faq_3.html#SEC102, adding the
`--enable-debugging' option to `../configure'. You can also contact the
mailing list for pointers (a simple test case that demonstrates the bug
is always welcome).  

How can I compile Cygwin for an unsupported platform
(PowerPC, Alpha, ARM, Itanium)?

Unfortunately, this will be difficult. Exception handling and signals
support semantics and args have been designed for x86 so you would need
to write specific support for your platform. We don't know of any other
incompatibilities. Please send us patches if you do this work!

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Christopher Faylor]

On Fri, Jan 21, 2005 at 07:04:50PM +0100, David Dindorp wrote:
>Corinna Vinschen wrote:
>>IMHO you're looking from the wrong direction.  People capable of
>>debugging the Cygwin DLL are usually also capable of building it.
>
>The only reason that the above is true is because you do not provide
>the means for people to debug the Cygwin DLL properly.

Actually, we do.  We provide the source code.  It's easy to build.

Have you even tried it?

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Christopher Faylor]

On Fri, Jan 21, 2005 at 05:28:38PM -0500, Pierre A. Humblet wrote:
>On Fri, Jan 21, 2005 at 02:47:20PM -0500, Christopher Faylor wrote:
>>On Fri, Jan 21, 2005 at 02:45:44PM -0500, Pierre A. Humblet wrote:
>>>On Fri, Jan 21, 2005 at 02:02:33PM -0500, Christopher Faylor wrote:
>>>> 
>>>>   tar xjf cygwin-1.5.12-1-src.tar.bz2
>>>>   cd cygwin-1.5.12-1
>>>>   mkdir build
>>>>   cd build
>>>>   (../configure; make) >& make.out
>>>> 
>>>>It does make sense to check CVS or a snapshot to see if your problem is
>>>>fixed before you go to any effort trying to debug a problem, however.
>>>
>>>Great.  Just put the above in the FAQ, plus some words about needing an
>>>unstripped dll.
>>
>>Information about building the DLL is already in the FAQ.
>
>If you refer to http://cygwin.com/faq/faq0.html#SEC102 it has the
>apparently obsolete information about needing a separate w32api and it
>recommends to use cvs.

You included the section where I said it was probably a good idea to use
CVS or a snapshot.  So, the FAQ is accurate there.  You're right that
the rest of it should be updated.

However, if the fact that the cygwin FAQ entry is mildly inaccurate was
a true stumbling block for people who wanted to debug the DLL, then I
think we would have seen a complaint about it by now.

I think it's pretty clear that the people who are clamoring for this
don't really know what they want and assume that a dll with debugging
symbols will either enable them to debug the dll without going through
the awful rigors of building or they think they would have a better
opportunity of having cygwin tech support look at their back traces.
Neither is precisely true.

However, I have already said that it is on my todo list to try to
provide a debuginfo package for cygwin.  It will show up in some
future release.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Pierre A. Humblet]

On Fri, Jan 21, 2005 at 02:47:20PM -0500, Christopher Faylor wrote:
> On Fri, Jan 21, 2005 at 02:45:44PM -0500, Pierre A. Humblet wrote:
> >On Fri, Jan 21, 2005 at 02:02:33PM -0500, Christopher Faylor wrote:
> >> 
> >>   tar xjf cygwin-1.5.12-1-src.tar.bz2
> >>   cd cygwin-1.5.12-1
> >>   mkdir build
> >>   cd build
> >>   (../configure; make) >& make.out
> >> 
> >> It does make sense to check CVS or a snapshot to see if your problem is
> >> fixed before you go to any effort trying to debug a problem, however.
> >
> >Great. Just put the above in the FAQ, plus some words about needing an
> >unstripped dll.
> 
> Information about building the DLL is already in the FAQ.

If you refer to http://cygwin.com/faq/faq0.html#SEC102
it has the apparently obsolete information about needing
a separate w32api and it recommends to use cvs.

Pierre

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Christopher Faylor]

On Fri, Jan 21, 2005 at 02:45:44PM -0500, Pierre A. Humblet wrote:
>On Fri, Jan 21, 2005 at 02:02:33PM -0500, Christopher Faylor wrote:
>> 
>>   tar xjf cygwin-1.5.12-1-src.tar.bz2
>>   cd cygwin-1.5.12-1
>>   mkdir build
>>   cd build
>>   (../configure; make) >& make.out
>> 
>> It does make sense to check CVS or a snapshot to see if your problem is
>> fixed before you go to any effort trying to debug a problem, however.
>
>Great. Just put the above in the FAQ, plus some words about needing an
>unstripped dll.

Information about building the DLL is already in the FAQ.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Christopher Faylor]

On Fri, Jan 21, 2005 at 02:26:39PM -0500, Igor Pechtchanski wrote:
>On Fri, 21 Jan 2005, Christopher Faylor wrote:
>
>> On Fri, Jan 21, 2005 at 11:53:25AM -0500, Igor Pechtchanski wrote:
>> >Also agreed.  But the source provided in the cygwin source package is
>> >worthless for debugging, since one can't build Cygwin from that source.
>> >If debugger symbols were available, that source would actually be
>> >useful.  :-)
>>
>> Huh?
>>
>>   tar xjf cygwin-1.5.12-1-src.tar.bz2
>>   cd cygwin-1.5.12-1
>>   mkdir build
>>   cd build
>>   (../configure; make) >& make.out
>>
>> This builds a cygwin DLL.  Just tried it.
>
>Whoops!  Apologies for providing outdated information...  At some point
>this required a CVS version of w32api, IIRC.
>
>For the archives, adding "--enable-debugging" to "../configure" above
>should build a debug version of the DLL.

I wouldn't suggest doing this unless you've been instructed to do so.
This adds extra debugging hooks into cygwin which provide more strace
output or pop up the debugger on certain types of situations.

The goal here is to build a version of the DLL which is the same as the
release.

The DLL that gets produced by the above has debugging symbols so this
is what is required.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Pierre A. Humblet]

On Fri, Jan 21, 2005 at 02:02:33PM -0500, Christopher Faylor wrote:
> 
>   tar xjf cygwin-1.5.12-1-src.tar.bz2
>   cd cygwin-1.5.12-1
>   mkdir build
>   cd build
>   (../configure; make) >& make.out
> 
> It does make sense to check CVS or a snapshot to see if your problem is
> fixed before you go to any effort trying to debug a problem, however.

Great. Just put the above in the FAQ, plus some words about needing an
unstripped dll.

Pierre


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Igor Pechtchanski]

On Fri, 21 Jan 2005, Christopher Faylor wrote:

> On Fri, Jan 21, 2005 at 11:53:25AM -0500, Igor Pechtchanski wrote:
> >Also agreed.  But the source provided in the cygwin source package is
> >worthless for debugging, since one can't build Cygwin from that source.
> >If debugger symbols were available, that source would actually be
> >useful.  :-)
>
> Huh?
>
>   tar xjf cygwin-1.5.12-1-src.tar.bz2
>   cd cygwin-1.5.12-1
>   mkdir build
>   cd build
>   (../configure; make) >& make.out
>
> This builds a cygwin DLL.  Just tried it.

Whoops!  Apologies for providing outdated information...  At some point
this required a CVS version of w32api, IIRC.

For the archives, adding "--enable-debugging" to "../configure" above
should build a debug version of the DLL.

> Since all of your arguments were presupposing something to do with CVS,
> I assume that this addresses your concerns.

Yes, it does.

> You don't need CVS and I did not say that you had to use CVS.
>
> It does make sense to check CVS or a snapshot to see if your problem is
> fixed before you go to any effort trying to debug a problem, however.

True, and others have made this point too.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Christopher Faylor]

On Fri, Jan 21, 2005 at 11:53:25AM -0500, Igor Pechtchanski wrote:
>Also agreed.  But the source provided in the cygwin source package is
>worthless for debugging, since one can't build Cygwin from that source.
>If debugger symbols were available, that source would actually be
>useful.  :-)

Huh?

  tar xjf cygwin-1.5.12-1-src.tar.bz2
  cd cygwin-1.5.12-1
  mkdir build
  cd build
  (../configure; make) >& make.out

This builds a cygwin DLL.  Just tried it.

Since all of your arguments were presupposing something to do with CVS,
I assume that this addresses your concerns.  You don't need CVS and I
did not say that you had to use CVS.

It does make sense to check CVS or a snapshot to see if your problem is
fixed before you go to any effort trying to debug a problem, however.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[David Dindorp]

Corinna Vinschen wrote:
> IMHO you're looking from the wrong direction.  People capable of
> debugging the Cygwin DLL are usually also capable of building it.

The only reason that the above is true is because you do not provide
the means for people to debug the Cygwin DLL properly.

> I'm wondering how somebody should be able to debug an application
> at all, if this person stumbles over using the compiler tools.

In the real world there is no strong binding between being able to
compile a properly functioning Cygwin DLL, and being able to look
through the source code, follow the developer's chain of thought and
figuring out why things do not work given the appropriate debug
information.  You imply that in order to compile a working Cygwin,
an intelligence quotient of X is required, while in order to debug it,
a higher intelligence quotient X + Y is required.
That's just not true.

Entirely different sets of skills are involved.

I'll admit though that being able to compile a functioning Cygwin
makes debugging easier by removing a lot of the brain work required,
and replacing it with simple trial-and-error.

That approach is unfortunately just plain impossible
when it comes to race conditions (eg.) or production systems.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Corinna Vinschen]

On Jan 21 11:53, Igor Pechtchanski wrote:
> On Fri, 21 Jan 2005, Christopher Faylor wrote:
> > On Fri, Jan 21, 2005 at 01:15:53PM +0100, Corinna Vinschen wrote:
> > >IMHO you're looking from the wrong direction.  People capable of
> > >debugging the Cygwin DLL are usually also capable of building it.  I'm
> > >wondering how somebody should be able to debug an application at all,
> > >if this person stumbles over using the compiler tools.
> >
> > cgf, waves and points.
> > See, Corinna is being mean here!  It's not just me!
> > (although I've made similar observations in the past)
> 
> She learned from the best... :-D

I'm slowly getting the drift ;-)


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Igor Pechtchanski]

On Fri, 21 Jan 2005, Christopher Faylor wrote:

> On Fri, Jan 21, 2005 at 01:15:53PM +0100, Corinna Vinschen wrote:
> >On Jan 21 11:18, Hughes, Bill wrote:
> >>I don't think I'm putting this very well, but it may make the FAQ
> >>easier if the standard advice is to load the snaphot and use that for
> >>debugging, it removes a separate layer of potential problems in
> >>building the dll.  I suspect the people who would want a stripped
> >>snapshot to be more capable of producing it than those would may need
> >>to build one with debug info.
> >
> >IMHO you're looking from the wrong direction.  People capable of
> >debugging the Cygwin DLL are usually also capable of building it.  I'm
> >wondering how somebody should be able to debug an application at all,
> >if this person stumbles over using the compiler tools.
>
> cgf, waves and points.
> See, Corinna is being mean here!  It's not just me!
> (although I've made similar observations in the past)

She learned from the best... :-D

> Maybe someone will prove me wrong but it seems likely that this is a
> basically an entry examination.  If you can't figure out how to build
> cygwin, then you probably aren't going to provide much in the way of
> useful feedback if you had a debuggable version.

Pierre already submitted an argument against this (the likelihood of the
bug may be reduced in CVS).  Here's another argument: it is sometimes
impractical to either replace the existing DLL or replicate the same exact
environment for a debug version.  Why not debug exactly what fails?

Besides, since the releases aren't tagged in CVS (yes, that old quibble
again), it's a gamble on whether you're even building the right version...

> I would also submit that, IMO, helping people run a debugger and figure
> things out in the debugger is an order of magnitude more difficult than
> providing basic tech support

Agreed.  So we don't teach them to debug, we simply provide them with
debugging symbols.

> The debugger is only marginally more useful when the debugging symbols
> are available anyway.  You still need the source code to do anything
> really worthwhile.

Also agreed.  But the source provided in the cygwin source package is
worthless for debugging, since one can't build Cygwin from that source.
If debugger symbols were available, that source would actually be useful.
:-)
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Christopher Faylor]

On Fri, Jan 21, 2005 at 01:15:53PM +0100, Corinna Vinschen wrote:
>On Jan 21 11:18, Hughes, Bill wrote:
>>I don't think I'm putting this very well, but it may make the FAQ
>>easier if the standard advice is to load the snaphot and use that for
>>debugging, it removes a separate layer of potential problems in
>>building the dll.  I suspect the people who would want a stripped
>>snapshot to be more capable of producing it than those would may need
>>to build one with debug info.
>
>IMHO you're looking from the wrong direction.  People capable of
>debugging the Cygwin DLL are usually also capable of building it.  I'm
>wondering how somebody should be able to debug an application at all,
>if this person stumbles over using the compiler tools.

cgf, waves and points.

See, Corinna is being mean here!  It's not just me!

(although I've made similar observations in the past)

Maybe someone will prove me wrong but it seems likely that this is a
basically an entry examination.  If you can't figure out how to build
cygwin, then you probably aren't going to provide much in the way of
useful feedback if you had a debuggable version.  I would also submit
that, IMO, helping people run a debugger and figure things out in the
debugger is an order of magnitude more difficult than providing basic
tech support

The debugger is only marginally more useful when the debugging symbols
are available anyway.  You still need the source code to do anything
really worthwhile.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Pierre A. Humblet]

On Fri, Jan 21, 2005 at 12:44:39PM +0100, Corinna Vinschen wrote:
> On Jan 20 17:00, Pierre A. Humblet wrote:
> > 
> > This must be modulated by the warnings on the snapshot page,
> > so I would recommend an initial step: write to the list, describe
> > the bug and ask for a recommended snapshot.
> > Should we also provide an optional cygwin_debug package, with only
> > an unstripped cygwin1.dll.debug ?
> 
> I don't think so.  I don't recall that any Linux distro contains a
> debug-enabled kernel.  I guess, those who feel confident to debug the
> kernel (here: the Cygwin DLL), should be able to build their own
> debug version.

Except that Cygwin changes at a high rate. Debugging a transient 
problem that shows up on 1.5.12 with the current cvs is taking a gamble.
There is a high probability you will first stumble on another bug.

If you have a debug dll, you can debug from a dump, or use the debug
dll in a production environment with just in time debugging enabled.
Once the bug is found, you may conclude it's gone from cvs, but that's
a firm (and satisfactory) conclusion. On the other hand if you can't
reproduce the bug with cvs, you don't know if it's really gone ot if
its likelihood is just reduced.

Pierre

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Corinna Vinschen]

On Jan 21 11:18, Hughes, Bill wrote:
> I don't think I'm putting this very well, but it may make the FAQ easier if
> the standard advice is to load the snaphot and use that for debugging, it
> removes a separate layer of potential problems in building the dll. I
> suspect the people who would want a stripped snapshot to be more capable of
> producing it than those would may need to build one with debug info.

IMHO you're looking from the wrong direction.  People capable of debugging
the Cygwin DLL are usually also capable of building it.  I'm wondering
how somebody should be able to debug an application at all, if this person
stumbles over using the compiler tools.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: cygwin bughunt (FAQ alert?)

[Hughes, Bill]

Christopher Faylor wrote:
..snip..
>> The snapshots page says that it's a stripped version.
>> Who should I trust, the snapshot page or the FAQ?
> 
> You should trust me when I tell you that the snapshots haven't been
> stripped recently. 
> 
> However, oops, this means that the advice of using a snapshot
> shouldn't go into the FAQ since this isn't a permanent arrangement.

Out of curiosity, would it make sense to always build the snapshot with the
debug info?
Thinking about the 'hierarchy of ignorance' for want of a better term, does
it require more knowledge to run gdb and give a sensible report or to build
the dll and then do the same?
I don't think I'm putting this very well, but it may make the FAQ easier if
the standard advice is to load the snaphot and use that for debugging, it
removes a separate layer of potential problems in building the dll. I
suspect the people who would want a stripped snapshot to be more capable of
producing it than those would may need to build one with debug info.

Bill
-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.tigris.org

This e-mail transmission is strictly confidential and intended solely
for the person or organisation to whom it is addressed. It may contain
privileged and confidential information and if you are not the intended
recipient, you must not copy, distribute or take any action in reliance
on it. If you have received this email in error, please reply to the
sender as soon as possible and delete the message. Please note that we
are able to, and reserve the right to, monitor e-mail communications
passing through our network.

The views expressed in this email are not that of the company unless
specified within the message.

The inclusion of this footnote indicates that the mail message and any
attachments have been checked for the presence of known viruses.

If you have any comments regarding our policy please direct them to
postmaster@cox.co.uk
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Corinna Vinschen]

On Jan 20 17:00, Pierre A. Humblet wrote:
> On Thu, Jan 20, 2005 at 12:47:33PM -0800, Joshua Daniel Franklin wrote:
> > 
> > Sure, how about this:
> > 
> > I've found a bug in Cygwin, how can I debug it?
> > 
> > Debugging symbols are stripped from distibuted Cygwin binaries, so any
> > symbols that you
> > see in gdb are basically meaningless. It is also a good idea to use
> > the latest code in case the bug has been fixed, so you will need to
> > either build your own debugging version by following the instructions
> > at http://cygwin.com/faq/faq_3.html#SEC102 or use a current snapshot
> > from http://cygwin.com/snapshots/
> 
> This must be modulated by the warnings on the snapshot page,
> so I would recommend an initial step: write to the list, describe
> the bug and ask for a recommended snapshot.
> Should we also provide an optional cygwin_debug package, with only
> an unstripped cygwin1.dll.debug ?

I don't think so.  I don't recall that any Linux distro contains a
debug-enabled kernel.  I guess, those who feel confident to debug the
kernel (here: the Cygwin DLL), should be able to build their own
debug version.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Joshua Daniel Franklin]

On Thu, 20 Jan 2005 19:24:03 -0500, Christopher Faylor wrote:
> However, oops, this means that the advice of using a snapshot shouldn't
> go into the FAQ since this isn't a permanent arrangement.

Well, how about this then:

I may have found a bug in Cygwin, how can I debug it (the symbols in gdb 
look funny)?

Debugging symbols are stripped from distibuted Cygwin binaries, so any
symbols that you see in gdb are basically meaningless. It is also a
good idea to use
the latest code in case the bug has been fixed, so you will need to follow the 
instructions at http://cygwin.com/faq/faq_3.html#SEC102 to build your own 
debugging version. You can also contact the mailing list for pointers
(a simple test
case that demonstrates the bug is always welcome).

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Christopher Faylor]

On Fri, Jan 21, 2005 at 12:56:14AM +0100, David Dindorp wrote:
>David Dindorp wrote:
>>Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was easy.
>
>Christopher Faylor wrote:
>>Since cygwin isn't built with debugging symbols, the symbols that you
>>do see in gdb are basically meaningless.
>
>Isn't there any way to compile the debugging symbols into a separate
>file that GDB could then play with if it wanted to?

Yes.  But it doesn't work quite right on cygwin, or at least didn't the
last time I looked at it.  It's on my todo to revisit this at some point.

However, that doesn't really solve your immediate concern.

>Joshua Daniel Franklin wrote:
>>> I think this has come up often enough to be a FAQ.  Joshua?
>> Sure, how about this:
>
>> either build your own debugging version by following the instructions
>> at http://cygwin.com/faq/faq_3.html#SEC102 or use a current snapshot
>> from http://cygwin.com/snapshots/
>
>Eep.  Totally overlooked the entire FAQ.  I apologize!!!
>
>The snapshots page says that it's a stripped version.
>Who should I trust, the snapshot page or the FAQ?

You should trust me when I tell you that the snapshots haven't been
stripped recently.

However, oops, this means that the advice of using a snapshot shouldn't
go into the FAQ since this isn't a permanent arrangement.

>Is it considered atrocious to just replace the DLL with a snapshot one
>and keep the EXE's from stock?

No, not at all.

>Pierre A.  Humblet wrote:
>>Should we also provide an optional cygwin_debug package, with only an
>>unstripped cygwin1.dll.debug ?
>
>I for one would be eternally grateful :-).  FWIW, MySQL AB does the
>same with MyODBC (in the same 'package' though).  I've found it useful
>a number of times.

Again, this doesn't address your immediate concern.  A snapshot is your
best bet.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[David Dindorp]

David Dindorp wrote:
> Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was
easy.

Christopher Faylor wrote:
> Since cygwin isn't built with debugging symbols, the symbols that you
do
> see in gdb are basically meaningless.

Isn't there any way to compile the debugging symbols into a separate
file
that GDB could then play with if it wanted to?


Joshua Daniel Franklin wrote:
>> I think this has come up often enough to be a FAQ.  Joshua?
> Sure, how about this:

> either build your own debugging version by following the instructions
> at http://cygwin.com/faq/faq_3.html#SEC102 or use a current snapshot
> from http://cygwin.com/snapshots/

Eep.  Totally overlooked the entire FAQ.  I apologize!!!

The snapshots page says that it's a stripped version.
Who should I trust, the snapshot page or the FAQ?

Is it considered atrocious to just replace the DLL with a snapshot one
and keep the EXE's from stock?


Pierre A. Humblet wrote:
> Should we also provide an optional cygwin_debug package, with only
> an unstripped cygwin1.dll.debug ?

I for one would be eternally grateful :-).
FWIW, MySQL AB does the same with MyODBC (in the same 'package' though).
I've found it useful a number of times.


'Arigato gozaimasu' *bows*.
--david



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Pierre A. Humblet]

On Thu, Jan 20, 2005 at 12:47:33PM -0800, Joshua Daniel Franklin wrote:
> 
> Sure, how about this:
> 
> I've found a bug in Cygwin, how can I debug it?
> 
> Debugging symbols are stripped from distibuted Cygwin binaries, so any
> symbols that you
> see in gdb are basically meaningless. It is also a good idea to use
> the latest code in case the bug has been fixed, so you will need to
> either build your own debugging version by following the instructions
> at http://cygwin.com/faq/faq_3.html#SEC102 or use a current snapshot
> from http://cygwin.com/snapshots/

This must be modulated by the warnings on the snapshot page,
so I would recommend an initial step: write to the list, describe
the bug and ask for a recommended snapshot.
Should we also provide an optional cygwin_debug package, with only
an unstripped cygwin1.dll.debug ?

Pierre

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Christopher Faylor]

On Thu, Jan 20, 2005 at 04:29:36PM -0500, Igor Pechtchanski wrote:
>On Thu, 20 Jan 2005, Joshua Daniel Franklin wrote:
>
>> > On Thu, Jan 20, 2005 at 08:12:31PM +0100, David Dindorp wrote:
>> > >Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was easy.
>> >
>> On Thu, 20 Jan 2005 15:04:55 -0500, Christopher Faylor wrote:
>> > Since cygwin isn't built with debugging symbols, the symbols that you do
>> > see in gdb are basically meaningless.
>> >
>> > I think this has come up often enough to be a FAQ.  Joshua?
>> >
>> > In any event, you do need to either build a debugging version or, possibly,
>> > use a snapshot from http://cygwin.com/snapshots/ since those are currently
>> > built with debugging turned on.
>>
>> Sure, how about this:
>>
>> I've found a bug in Cygwin, how can I debug it?
>>
>> Debugging symbols are stripped from distibuted Cygwin binaries, so any
>> symbols that you see in gdb are basically meaningless. It is also a good
>> idea to use the latest code in case the bug has been fixed, so you will
>> need to either build your own debugging version by following the
>> instructions at http://cygwin.com/faq/faq_3.html#SEC102 or use a current
>> snapshot from http://cygwin.com/snapshots/
>
>The entry is good, but the title implies (*GASP*) that there may be bugs
>in Cygwin.  I'd suggest something like "I'm debugging within the Cygwin
>DLL space, and gdb shows garbage symbols.  How do I debug Cygwin?"

It is guaranteed that there are bugs in cygwin so I don't have any problems
with using this terminology.  However maybe it could be softented to something
like "I may have found a bug in Cygwin..."

An additional entry might be "Why do the symbols look funny when I try to
debug Cygwin?"

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Igor Pechtchanski]

On Thu, 20 Jan 2005, Joshua Daniel Franklin wrote:

> > On Thu, Jan 20, 2005 at 08:12:31PM +0100, David Dindorp wrote:
> > >Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was easy.
> >
> On Thu, 20 Jan 2005 15:04:55 -0500, Christopher Faylor wrote:
> > Since cygwin isn't built with debugging symbols, the symbols that you do
> > see in gdb are basically meaningless.
> >
> > I think this has come up often enough to be a FAQ.  Joshua?
> >
> > In any event, you do need to either build a debugging version or, possibly,
> > use a snapshot from http://cygwin.com/snapshots/ since those are currently
> > built with debugging turned on.
>
> Sure, how about this:
>
> I've found a bug in Cygwin, how can I debug it?
>
> Debugging symbols are stripped from distibuted Cygwin binaries, so any
> symbols that you see in gdb are basically meaningless. It is also a good
> idea to use the latest code in case the bug has been fixed, so you will
> need to either build your own debugging version by following the
> instructions at http://cygwin.com/faq/faq_3.html#SEC102 or use a current
> snapshot from http://cygwin.com/snapshots/

The entry is good, but the title implies (*GASP*) that there may be bugs
in Cygwin.  I'd suggest something like "I'm debugging within the Cygwin
DLL space, and gdb shows garbage symbols.  How do I debug Cygwin?"
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Christopher Faylor]

On Thu, Jan 20, 2005 at 12:47:33PM -0800, Joshua Daniel Franklin wrote:
>> On Thu, Jan 20, 2005 at 08:12:31PM +0100, David Dindorp wrote:
>> >Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was easy.
>> 
>On Thu, 20 Jan 2005 15:04:55 -0500, Christopher Faylor wrote:
>> Since cygwin isn't built with debugging symbols, the symbols that you do
>> see in gdb are basically meaningless.
>> 
>> I think this has come up often enough to be a FAQ.  Joshua?
>> 
>> In any event, you do need to either build a debugging version or, possibly,
>> use a snapshot from http://cygwin.com/snapshots/ since those are currently
>> built with debugging turned on.
>
>Sure, how about this:
>
>I've found a bug in Cygwin, how can I debug it?
>
>Debugging symbols are stripped from distibuted Cygwin binaries, so any
>symbols that you
>see in gdb are basically meaningless. It is also a good idea to use
>the latest code in case the bug has been fixed, so you will need to
>either build your own debugging version by following the instructions
>at http://cygwin.com/faq/faq_3.html#SEC102 or use a current snapshot
>from http://cygwin.com/snapshots/

Poifect.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Joshua Daniel Franklin]

> On Thu, Jan 20, 2005 at 08:12:31PM +0100, David Dindorp wrote:
> >Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was easy.
> 
On Thu, 20 Jan 2005 15:04:55 -0500, Christopher Faylor wrote:
> Since cygwin isn't built with debugging symbols, the symbols that you do
> see in gdb are basically meaningless.
> 
> I think this has come up often enough to be a FAQ.  Joshua?
> 
> In any event, you do need to either build a debugging version or, possibly,
> use a snapshot from http://cygwin.com/snapshots/ since those are currently
> built with debugging turned on.

Sure, how about this:

I've found a bug in Cygwin, how can I debug it?

Debugging symbols are stripped from distibuted Cygwin binaries, so any
symbols that you
see in gdb are basically meaningless. It is also a good idea to use
the latest code in case the bug has been fixed, so you will need to
either build your own debugging version by following the instructions
at http://cygwin.com/faq/faq_3.html#SEC102 or use a current snapshot
from http://cygwin.com/snapshots/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bughunt (FAQ alert?)

[Christopher Faylor]

On Thu, Jan 20, 2005 at 08:12:31PM +0100, David Dindorp wrote:
>Larry Hall wrote:
>
>> I have the following suggestions/questions:
>
>>  1. Did you try a Cygwin 1.5.12 or even a snapshot?
>
>No.  I'm using 1.5.10, and it still smells *real* fresh, I think ;-).
>
>Also, the problem only occurs on a customer system which unfortunately
>I can't go around and upgrade all the time "just to see".
>I don't have regular access to it either.
>
>
>>  2. Is this a local debug build of Cygwin or stock 1.5.10.  If the 
>>     latter, you might find building a debug version is more help.
>
>Stock 1.5.10.
>There's a debug version?  These are the things I need to know!
>Found the "how-to-debug-cygwin" document buried deep in some bz2 file,
>I'll go read that now.
>
>In the above statement, you sort-of imply that building a debug version
>is wrong if using a stock version..  I should do what then?
>
>
>> If there is a race issue here, you're going to need to work with the 
>> code to find it.
>
>That's what I'm basically trying to do.
>Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was easy.

Since cygwin isn't built with debugging symbols, the symbols that you do
see in gdb are basically meaningless.

I think this has come up often enough to be a FAQ.  Joshua?

In any event, you do need to either build a debugging version or, possibly,
use a snapshot from http://cygwin.com/snapshots/ since those are currently
built with debugging turned on.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/