Re: cygwin bughunt (FAQ alert?)
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?)
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?)
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?)
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 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 VersionStatus _update-info-dir 00231-1OK 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 bzip21.0.2-6OK coreutils5.2.1-5OK crypt1.1-1 OK cygutils 1.2.5-1OK cygwin 1.5.12-1 OK cygwin-doc 1.4-1 OK diffutils2.8.7-1OK editrights 1.01-1 OK expat1.95.8-1 OK findutils20041227-1 OK gawk 3.1.4-3OK gcc 3.3.3-3OK gcc-core 3.3.3-3OK gcc-g++ 3.3.3-3OK gcc-mingw-core 20040810-1 OK gcc-mingw-g++20040810-1 OK gdbm 1.8.3-7OK grep 2.5-1 OK groff1.18.1-2 OK gzip 1.3.5-1OK less 381-1 OK libbz2_1 1.0.2-6OK libcharset1 1.9.2-1OK libdb4.2 4.2.52-1 OK libgdbm 1.8.0-5OK libgdbm-devel1.8.3-7OK libgdbm3 1.8.3-3OK libgdbm4 1.8.3-7OK libiconv 1.9.2-1OK libiconv21.9.2-1OK 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-4OK libreadline4 4.1-2 OK libreadline5 4.3-5 OK libreadline6 5.0-1 OK login1.9-7 OK make 3.80-1 OK man 1.5o1-1OK mingw-runtime3.7-1 OK mktemp 1.5-3 OK ncurses 5.4-1 OK perl 5.8.6-2OK readline 5.0-1 OK sed 4.1.2-1OK 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 which1.6-1 OK zlib 1.2.2-1OK 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?)
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?)
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/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,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?)
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?)
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?)
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 21 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?)
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?)
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?)
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?)
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?)
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 [EMAIL PROTECTED] 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?)
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?)
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 [EMAIL PROTECTED] 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?)
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?)
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?)
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/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,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?)
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?)
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?)
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?)
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/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,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?)
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?)
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?)
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?)
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?)
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?)
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?)
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/
Re: cygwin bughunt (FAQ alert?)
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?)
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?)
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/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,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?)
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?)
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?)
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?)
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?)
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/
