Re: Another problem using GDB
Hi! Thursday, 17 October, 2002 Thomas Mellman [EMAIL PROTECTED] wrote: TM I'm having another problem with GDB. Normally, one would debug a core file TM as follows (correct?): TM gdb -nw gtl.exe gtl.exe.stackdump *.stackdump is not a corefile. To create core file, use 'dumper' utility, supplied with cygwin. Then you can debug created gtl.exe.core by issuing 'gdb --core=gtl.exe.core' command. Documentation on using dumper should be present in User's manual. Egor.mailto:deo;logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Re: Another problem using GDB
On Thu, Oct 17, 2002 at 10:06:21AM -0400, [EMAIL PROTECTED] wrote: I'd highly recommend thoroughly exploring the information provided at www.cygwin.com for answers before resorting to any external web site for Cygwin information. While there may be good information on Cygwin elsewhere, it's the Cygwin web site that gets the most scrutiny and is a much more reliable source of quality information overall. To be honest, it's a real goal to have this site be the one-stop shopping for all your Cygwin needs. Folks who want to disseminate Cygwin information are encouraged to do it at the Cygwin web site. But that's a bit of a different issue. ;-) In any case, the Cygwin community maintains the Cygwin web site only and strives to keep it current, correct, and useful. Other sites are outside our control and in general, not recommended resources. Hmmm, although that's a nice sentiment that I appreciate, I thought that I'd seen C. Faylor say that we should be looking at Google for answers rather than pestering the list ... On a related issue, I can't use the search function in the mail archives - it always times out on me ... Thomas Mellman [EMAIL PROTECTED] Mobile +49/162/806-8405 Fax +49/1212/5 115 48 103 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Re: Another problem using GDB
egor duda [EMAIL PROTECTED] schrieb am 17.10.02 12:10:42: Hi! Thursday, 17 October, 2002 Thomas Mellman [EMAIL PROTECTED] wrote: TM I'm having another problem with GDB. Normally, one would debug a core file TM as follows (correct?): TM gdb -nw gtl.exe gtl.exe.stackdump *.stackdump is not a corefile. To create core file, use 'dumper' utility, supplied with cygwin. Then you can debug created gtl.exe.core by issuing 'gdb --core=gtl.exe.core' command. Thank you. I guess this webpage is wrong, which I'd found looking for gdb stackdump in order to find instructions: http://aubit4gl.sourceforge.net/aubit4gldoc/manual/html/faq.html You can use gdb --nw to run debugger in CUI mode, not GUI gdb --nw 4glc.exe 4glc.exe.stackdump -- Thomas Mellman [EMAIL PROTECTED] Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr! Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Dumper.exe doesn't work with libintl2-0.11.5-1. Was: RE: Another problem using GDB
Found 2 matches for cygintl-2.dll. libintl2/libintl2-0.11.2-2 GNU Internationalization runtime library libintl2/libintl2-0.11.5-1 GNU Internationalization runtime library I had 0.11.5-1 installed (I reinstalled it just to be sure). It still didn't work. I tried backing out to 0.11.2-2, and it worked fine. I'm running the dumper.exe from cygwin 1.3.13-2. -Rolf -Original Message- From: Christopher Faylor [mailto:cgf;redhat.com] Sent: Thursday, October 17, 2002 12:32 PM To: [EMAIL PROTECTED] Subject: Re: Another problem using GDB On Thu, Oct 17, 2002 at 09:28:51AM -0400, Rolf Campbell wrote: When I try to use dumper, I get an msgbox The procedure entry point dcgettext__ could not be located in the dynamic link library cygintl-2.dll. http://cygwin.com/packages/ Search for cygintl-2.dll Install that package. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Another problem using GDB
On Thu, Oct 17, 2002 at 09:28:51AM -0400, Rolf Campbell wrote: When I try to use dumper, I get an msgbox The procedure entry point dcgettext__ could not be located in the dynamic link library cygintl-2.dll. http://cygwin.com/packages/ Search for cygintl-2.dll Install that package. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Re: Another problem using GDB
On Thu, Oct 17, 2002 at 10:06:21AM -0400, [EMAIL PROTECTED] wrote: I'd highly recommend thoroughly exploring the information provided at www.cygwin.com for answers before resorting to any external web site for Cygwin information. While there may be good information on Cygwin elsewhere, it's the Cygwin web site that gets the most scrutiny and is a much more reliable source of quality information overall. To be honest, it's a real goal to have this site be the one-stop shopping for all your Cygwin needs. Folks who want to disseminate Cygwin information are encouraged to do it at the Cygwin web site. But that's a bit of a different issue. ;-) In any case, the Cygwin community maintains the Cygwin web site only and strives to keep it current, correct, and useful. Other sites are outside our control and in general, not recommended resources. Yep. Good advice since, in this case, the web page is 100% wrong and we don't want to be policing other people's web pages. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Re: Another problem using GDB
On Thu, Oct 17, 2002 at 08:48:12PM +0200, [EMAIL PROTECTED] wrote: On Thu, Oct 17, 2002 at 10:06:21AM -0400, [EMAIL PROTECTED] wrote: I'd highly recommend thoroughly exploring the information provided at www.cygwin.com for answers before resorting to any external web site for Cygwin information. While there may be good information on Cygwin elsewhere, it's the Cygwin web site that gets the most scrutiny and is a much more reliable source of quality information overall. To be honest, it's a real goal to have this site be the one-stop shopping for all your Cygwin needs. Folks who want to disseminate Cygwin information are encouraged to do it at the Cygwin web site. But that's a bit of a different issue. ;-) In any case, the Cygwin community maintains the Cygwin web site only and strives to keep it current, correct, and useful. Other sites are outside our control and in general, not recommended resources. Hmmm, although that's a nice sentiment that I appreciate, I thought that I'd seen C. Faylor say that we should be looking at Google for answers rather than pestering the list ... I generally tell people to use the resources at the project web site when it is a cygwin question. I don't recall telling people to read documentation elsewhere -- quite the contrary I've frequently asked people to contribute documentation improvements here. However, if you want to use google, then, as long as you are vaguely remembering what has been said, let me refresh your memory: Add a site:cygwin.com to the search term. On a related issue, I can't use the search function in the mail archives - it always times out on me ... Works fine here. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Re: Another problem using GDB
OK, maybe I didn't say this right. Let me try again. Please treat all information as provided by the Cygwin web site as superior to information derived from other web sites when researching Cygwin. It's not necessary to use the Cygwin email archives search engine to find information on the Cygwin site (although this is not a discouraged mechanism either, assuming you're looking for information in the Cygwin email archives). But if there are two sources of information for a Cygwin topic you're researching, choose the Cygwin site as paramount if that's an option. If you find the information from the Cygwin site to be incorrect, let the email list know ([EMAIL PROTECTED]). If you find information about Cygwin at another site which is wrong, let that site know. If you can't find any information that's helpful in your research, ask the list ([EMAIL PROTECTED]). It's appropriate to query the list if you've done due diligence in your research but still can't find an answer. Does that help clarify things? Larry Original Message: - From: [EMAIL PROTECTED] Date: Thu, 17 Oct 2002 20:48:12 +0200 To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Re: Another problem using GDB On Thu, Oct 17, 2002 at 10:06:21AM -0400, [EMAIL PROTECTED] wrote: I'd highly recommend thoroughly exploring the information provided at www.cygwin.com for answers before resorting to any external web site for Cygwin information. While there may be good information on Cygwin elsewhere, it's the Cygwin web site that gets the most scrutiny and is a much more reliable source of quality information overall. To be honest, it's a real goal to have this site be the one-stop shopping for all your Cygwin needs. Folks who want to disseminate Cygwin information are encouraged to do it at the Cygwin web site. But that's a bit of a different issue. ;-) In any case, the Cygwin community maintains the Cygwin web site only and strives to keep it current, correct, and useful. Other sites are outside our control and in general, not recommended resources. Hmmm, although that's a nice sentiment that I appreciate, I thought that I'd seen C. Faylor say that we should be looking at Google for answers rather than pestering the list ... On a related issue, I can't use the search function in the mail archives - it always times out on me ... Thomas Mellman [EMAIL PROTECTED] Mobile +49/162/806-8405 Fax +49/1212/5 115 48 103 mail2web - Check your email from the web at http://mail2web.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Dumper.exe doesn't work with libintl2-0.11.5-1. Was: RE: Another problem using GDB
Rolf Campbell wrote: Found 2 matches for cygintl-2.dll. libintl2/libintl2-0.11.2-2 GNU Internationalization runtime library libintl2/libintl2-0.11.5-1 GNU Internationalization runtime library I had 0.11.5-1 installed (I reinstalled it just to be sure). It still didn't work. I tried backing out to 0.11.2-2, and it worked fine. I'm running the dumper.exe from cygwin 1.3.13-2. Thanks for the tip -- you are correct that the binary interface of libintl changed between 0.11.2 and 0.11.5 (I didn't notice earlier because it was NOT flagged in the NEWS or ChangeLog...Gand the problem only shows up rarely. Most apps don't use the foo__ aliases.) Unfortunately, I can't fix this. Bruno changed the export aliases from 'foo__ to libintl_foo -- but he didn't bump the 'LTV_CURRENT' variable in intl/Makefile.in. This is his mistake, and I suppose for the official cygwin release I *could* 1) repackage gettext-0.11.2-2's cygintl-2.dll as 'libintl2' 2) bump gettext-0.11.5's LTV_CURRENT to '5' (LTV_AGE = 2, so dllnum = 3) 3) respin gettext-0.11.5-2 with a new 'libintl3' package containing cygintl-3.dll. But that means that the official gettext package on cygwin will build differently than the gettext code placed into projects by the 'gettextize' command -- and worse, Bruno *specifically* says right in the relevant Makefile: # Before making a gettext release, the gettext maintainer must change this # according to the libtool documentation, section Library interface versions. # Maintainers of other packages that include the intl directory must *not* # change these values. I think gettext maintainer is *not* me, but Bruno. So, we're left with an updated DLL that *may* break existing apps, and they need to be recompiled against the new library. Blech. This conflict only happens if the app in question, for whatever reason, uses the internal alias foo__ / libintl_foo instead of directly calling foo. (in dumper's case, 'dcgettext__' instead of just 'dcgettext') I'm not sure what triggers using the alias; it **seems** to be triggered by configuring the application with '--with-included-gettext' -- but if THAT's the case, then the app shouldn't be using MY gettext DLL at all!; instead it (dumper.exe, in this case) should be using its own local convenience/staticlib version of libintl. That's the whole point of the aliased names... Given that it took a month for this problem to surface, I surmise that not many apps will exhibit this problem. Recommend that we maintain source compatibility with Bruno's official release, and break technical binary compatibility with earlier 'cygintl-2.dll' versions. This means that offending programs, that *happen* to exhibit this behavior, need to be recompiled against the newer gettext library. The latest cygwin snapshots have been compiled against the new cygintl-2.dll, so that takes care of dumper.exe. If you need dumper (and not many people do), then download the latest 'cygwin-inst' snapshot and extract dumper.exe from it. It will *probably* work ok with the 1.3.13-2 DLL, but no guarantees. In any case, this problem will go away once 1.3.13-3 is released. --Chuck [still not back for real -- but I'm breaking my silence because arguably, this goof is my fault. It's more complicated than that, but I felt I needed to explain it -- and why I'm not going to respin gettext to fix the problem] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Another problem using GDB
Cygwin normally does not produce core dumps, but only simple textual stack backtraces (try to look at gtl.exe.stackdump using your text editor). However, you can have full core dumps using dumper utility; see http://cygwin.com/cygwin-ug-net/using-utils.html#DUMPER for details. Pavel [EMAIL PROTECTED] wrote: I'm having another problem with GDB. Normally, one would debug a core file as follows (correct?): gdb -nw gtl.exe gtl.exe.stackdump Unfortunately, I get the following in response: GNU gdb 5.0 (20010428-3) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-cygwin... /home/w/src/gtl/gtl.exe.stackdump is not a core dump: File format not recognized (gdb) Is this an operator error? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
