bzip2-1.0.2 from official home page not working with Cygwin
I'm trying to build a stand alone libbz2 compiled with -mno-cygwin so I grabbed the source from http://sources.redhat.com/bzip2/ rather than using the version that comes with Cygwin. Running make produces warnings and one of the tests fails. Below is the output using gcc 3.3.1-3. -Karl > $ make > > If compilation produces errors, or a large number of warnings, > please read README.COMPILATION.PROBLEMS -- you might be able to > adjust the flags in this Makefile to improve matters. > > gcc -Wall -Winline -O2 -fomit-frame-pointer -fno-strength-reduce -c > blocksort.c > > blocksort.c: In function `fallbackQSort3': > blocksort.c:83: warning: inlining failed in call to `fallbackSimpleSort' > blocksort.c:162: warning: called from here > blocksort.c: In function `mainSimpleSort': > blocksort.c:400: warning: inlining failed in call to `mainGtU' > blocksort.c:561: warning: called from here > blocksort.c:400: warning: inlining failed in call to `mainGtU' > blocksort.c:575: warning: called from here > blocksort.c:400: warning: inlining failed in call to `mainGtU' > blocksort.c:589: warning: called from here > gcc -Wall -Winline -O2 -fomit-frame-pointer -fno-strength-reduce -c > huffman.c gcc -Wall -Winline -O2 -fomit-frame-pointer -fno-strength-reduce > -c crctable.c > gcc -Wall -Winline -O2 -fomit-frame-pointer -fno-strength-reduce -c > randtable.c > > gcc -Wall -Winline -O2 -fomit-frame-pointer -fno-strength-reduce -c > compress.c > gcc -Wall -Winline -O2 -fomit-frame-pointer -fno-strength-reduce -c > decompress. > c > gcc -Wall -Winline -O2 -fomit-frame-pointer -fno-strength-reduce -c > bzlib.c rm -f libbz2.a > ar cq libbz2.a blocksort.o huffman.o crctable.o randtable.o compress.o > decompres > s.o bzlib.o > ranlib libbz2.a > gcc -Wall -Winline -O2 -fomit-frame-pointer -fno-strength-reduce -c > bzip2.c bzip2.c: In function `uncompressStream': > bzip2.c:557: warning: dereferencing type-punned pointer will break > strict-aliasing rules > bzip2.c: In function `testStream': > bzip2.c:665: warning: dereferencing type-punned pointer will break > strict-aliasi > ng rules > gcc -Wall -Winline -O2 -fomit-frame-pointer -fno-strength-reduce -o bzip2 > bzip > 2.o -L. -lbz2 > gcc -Wall -Winline -O2 -fomit-frame-pointer -fno-strength-reduce -c > bzip2recove > r.c > gcc -Wall -Winline -O2 -fomit-frame-pointer -fno-strength-reduce -o > bzip2recov > er bzip2recover.o > > Doing 6 tests (3 compress, 3 uncompress) ... > If there's a problem, things might stop at this point. > > ./bzip2 -1 < sample1.ref > sample1.rb2 > ./bzip2 -2 < sample2.ref > sample2.rb2 > ./bzip2 -3 < sample3.ref > sample3.rb2 > ./bzip2 -d < sample1.bz2 > sample1.tst > ./bzip2 -d < sample2.bz2 > sample2.tst > ./bzip2 -ds < sample3.bz2 > sample3.tst > cmp sample1.bz2 sample1.rb2 > cmp sample2.bz2 sample2.rb2 > cmp sample3.bz2 sample3.rb2 > sample3.bz2 sample3.rb2 differ: char 11, line 1 > make: *** [test] Error 1 -- 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: bzip2-1.0.2 from official home page not working with Cygwin
Hallo Karl, Am Samstag, 3. Januar 2004 um 09:47 schriebst du: > I'm trying to build a stand alone libbz2 compiled with -mno-cygwin so I > grabbed the source from http://sources.redhat.com/bzip2/ rather than using > the version that comes with Cygwin. I don't see the -mno-cygwin flag in the output you quoted. > Running make produces warnings and one of the tests fails. Below is the > output using gcc 3.3.1-3. There is a (small) patch included in the Cygwin source package, maybe that helps? Building with the Cygwin source package and 'CC=gcc -mno-cygwin' I got this: Doing 6 tests (3 compress, 3 uncompress) ... If there's a problem, things might stop at this point. ./bzip2 -1 < sample1.ref > sample1.rb2 ./bzip2 -2 < sample2.ref > sample2.rb2 ./bzip2 -3 < sample3.ref > sample3.rb2 ./bzip2 -d < sample1.bz2 > sample1.tst ./bzip2 -d < sample2.bz2 > sample2.tst ./bzip2 -ds < sample3.bz2 > sample3.tst cmp sample1.bz2 sample1.rb2 cmp sample2.bz2 sample2.rb2 cmp sample3.bz2 sample3.rb2 cmp sample1.tst sample1.ref cmp sample2.tst sample2.ref cmp sample3.tst sample3.ref If you got this far and the "cmp"s didn't complain, it looks like you're in business. [...] $ cygcheck *.exe Found: .\bzip2-stat.exe bzip2-stat.exe C:\WINNT\System32\msvcrt.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\ntdll.dll Found: .\bzip2.exe Found: H:\bin\bzip2.exe Found: H:\\bin\bzip2.exe bzip2.exe .\cygbz2-1.dll C:\WINNT\System32\msvcrt.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\ntdll.dll Found: .\bzip2recover-stat.exe bzip2recover-stat.exe C:\WINNT\System32\msvcrt.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\ntdll.dll Found: .\bzip2recover.exe Found: H:\bin\bzip2recover.exe Found: H:\\bin\bzip2recover.exe bzip2recover.exe C:\WINNT\System32\msvcrt.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\ntdll.dll Gerrit -- =^..^= -- 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: Fw: Bug in fstream code and gcc-2 package?
At 06:58 AM 1/3/2004, John Maddock wrote: >Beman, > >Here's the reply I got from the cygwin list on this, can you reply with >details of your system and the fact that it fails there? John's fstream.cpp test program fails on my Win XP SP 1 system. I've reinstalled cygwin gcc and mingw components freshly downloaded. The gcc and gcc-g++ .tar.bz2 files are identified as 3.3.1-3. The mingw-runtime id is 3.2-1. The command line I'm using is simply: g++ fstream.cpp Executing the resulting program results in: 2 [main] a 1668 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 413 [main] a 1668 open_stackdumpfile: Dumping stack trace to a.exe.stackdump The program compiles and executes correctly with Borland, Intel, Metrowerks, and Microsoft compilers. Any suggestions? This is the system used to run the Boost Win32 regression tests, and we would like to eliminate as many gcc/cygwin failures as possible. See http://boost.sourceforge.net/regression-logs/ Thanks, --Beman Dawes > >Many thanks, > >John. > >- Original Message - >From: "Larry Hall" <[EMAIL PROTECTED]> >To: "John Maddock" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> >Sent: Friday, January 02, 2004 2:46 PM >Subject: Re: Bug in fstream code and gcc-2 package? > > >> At 07:54 AM 1/2/2004, John Maddock you wrote: >> >The following example code works cleanly on all the platforms I've >tested >> >on, except the gcc-2 package where it segfaults: >> >> >> The gcc-2 package has been removed as a package from Cygwin mirrors (or >> should be) and is no longer supported. Try it with the current Cygwin >> gcc/g++ package (3.3.1). Your code executes without a crash there. >> >> >> >> -- >> Larry Hall http://www.rfk.com >> RFK Partners, Inc. (508) 893-9779 - RFK Office >> 838 Washington Street (508) 893-9889 - FAX >> Holliston, MA 01746 >> >> -- 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: pthreads, printf and cout
"Christopher Faylor" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Fri, Jan 02, 2004 at 07:57:37PM +0200, Alex Vinokur wrote: > >Hi, > > > >Behavior of printf and cout in a program below is different : cout prints nothing. > > > >What is wrong? > > > >=== > >Windows 2000 Professional > >CYGWIN_NT-5.0 1.5.4(0.94/3/2) > >gcc version 3.3.1 (cygming special) > >=== > > For starters, what's wrong is that you are using an old version of > cygwin. It does no one a service to report bugs against a non-current > version. > I have upgraded cygwin. - $ uname -sroi CYGWIN_NT-5.0 1.5.5(0.94/3/2) unknown Cygwin $ cygcheck -c | grep cygwin cygwin 1.5.5-1OK $ g++ --version g++ (GCC) 3.3.1 (cygming special) [---omitted---] - Now pthreads and cout work fine. Thanks, -- Alex Vinokur mailto:[EMAIL PROTECTED] http://mathforum.org/library/view/10978.html -- 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/
new snapshot with some tty/WinMe fixes
I managed to get a WinMe installation up and running here so I can now debug some of the problems that show up there. And, they were interesting problems indeed. It seems like something sometimes starts up a stray thread on WinMe and that thread does not register itself with the new signal handler. It somehow doesn't even go through the DLL thread initialization code. So, all of my new code which allows signals to threads got confused by this. I've worked around this in an ugly way but at least I am not seeing the random failures that I was consistently getting. I will run the testsuite on this soon to see if it there are any more gotchas but I thought I'd get a new version uploaded. I also noticed YA handle leak in the new tty inheritance code with my old friend vfork, so I have hopefully fixed that. I tried all of the test cases that Pierre previously reported but I'm sure I missed one. I didn't change any of the fork handling, AFAIK, just vfork. That means that /bin/sh and make are potentially affected. 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: Bug in fstream code and gcc-2 package?
Hallo Beman, I cannot reproduce it here on my NT4 SP 6a: $ uname -svr CYGWIN_NT-4.0 1.5.5(0.94/3/2) 2003-09-20 16:31 $ cygcheck -c gcc Cygwin Package Information Package VersionStatus gcc 3.3.1-3OK $ cygcheck -c gcc-g++ Cygwin Package Information Package VersionStatus gcc-g++ 3.3.1-3OK $ g++ fstream.cpp $ ls a.exe* fstream.cpp $ ./a $ cygcheck a Found: .\a.exe a.exe H:\bin\cygwin1.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\ntdll.dll $ g++ -mno-cygwin fstream.cpp $ ls a.exe* fstream.cpp $ ./a $ cygcheck a Found: .\a.exe a.exe C:\WINNT\System32\msvcrt.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\ntdll.dll Can you run it with gdb and try to figure out what fails for you? Gerrit Am Samstag, 3. Januar 2004 um 15:39 schriebst du: > At 06:58 AM 1/3/2004, John Maddock wrote: >>Beman, >> >>Here's the reply I got from the cygwin list on this, can you reply with >>details of your system and the fact that it fails there? > John's fstream.cpp test program fails on my Win XP SP 1 system. I've > reinstalled cygwin gcc and mingw components freshly downloaded. The gcc and > gcc-g++ .tar.bz2 files are identified as 3.3.1-3. The mingw-runtime id is > 3.2-1. > The command line I'm using is simply: g++ fstream.cpp > Executing the resulting program results in: >2 [main] a 1668 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION > 413 [main] a 1668 open_stackdumpfile: Dumping stack trace to > a.exe.stackdump > The program compiles and executes correctly with Borland, Intel, > Metrowerks, and Microsoft compilers. > Any suggestions? This is the system used to run the Boost Win32 regression > tests, and we would like to eliminate as many gcc/cygwin failures as > possible. See http://boost.sourceforge.net/regression-logs/ > Thanks, > --Beman Dawes >> >>Many thanks, >> >>John. >> >>- Original Message - >>From: "Larry Hall" <[EMAIL PROTECTED]> >>To: "John Maddock" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> >>Sent: Friday, January 02, 2004 2:46 PM >>Subject: Re: Bug in fstream code and gcc-2 package? >> >> >>> At 07:54 AM 1/2/2004, John Maddock you wrote: >>> >The following example code works cleanly on all the platforms I've >>tested >>> >on, except the gcc-2 package where it segfaults: >>> >>> >>> The gcc-2 package has been removed as a package from Cygwin mirrors (or >>> should be) and is no longer supported. Try it with the current Cygwin >>> gcc/g++ package (3.3.1). Your code executes without a crash there. >>> >>> >>> >>> -- >>> Larry Hall http://www.rfk.com >>> RFK Partners, Inc. (508) 893-9779 - RFK Office >>> 838 Washington Street (508) 893-9889 - FAX >>> Holliston, MA 01746 >>> >>> -- =^..^= -- 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: Bug in fstream code and gcc-2 package?
At 04:12 PM 1/3/2004, Gerrit P. Haase you wrote: >Hallo Beman, > >I cannot reproduce it here on my NT4 SP 6a: In case it's of any interest, the version that I compiled was the same as Gerrit's in every way except it was on W2K + SP3. >Can you run it with gdb and try to figure out what fails for you? I can't find fault with this suggestion. ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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: new snapshot with some tty/WinMe fixes
At 01:19 PM 1/3/2004 -0500, Christopher Faylor wrote: >I managed to get a WinMe installation up and running here so I can now >debug some of the problems that show up there. And, they were >interesting problems indeed. It seems like something sometimes starts >up a stray thread on WinMe and that thread does not register itself with >the new signal handler. It somehow doesn't even go through the DLL >thread initialization code. So, all of my new code which allows signals >to threads got confused by this. > >I've worked around this in an ugly way but at least I am not seeing >the random failures that I was consistently getting. I will run >the testsuite on this soon to see if it there are any more gotchas >but I thought I'd get a new version uploaded. > >I also noticed YA handle leak in the new tty inheritance code with >my old friend vfork, so I have hopefully fixed that. I tried all >of the test cases that Pierre previously reported but I'm sure I >missed one. I didn't change any of the fork handling, AFAIK, just >vfork. That means that /bin/sh and make are potentially affected. CYGWIN_ME-4.90 hpn5170x 1.5.6s(0.108/3/2) 20040103 13:16:07 i686 unknown unknown Cygwin 1) With the snapshot I can start cygwin programs fine and I have not observed any popup. 2) The regression repeated before (see original mail for more details) is still there: "However when using sh, setsid sh -c "echo hello > /dev/tty1; /bin/sleep 10; /bin/echo there > /dev/tty" sh and the final echo hang forever (with echo in the "O" state in ps), and sh cannot be terminated with kill (OK from the task manager)." 3) There is another regression that I had also observed with the previous snapshot, but after sending my previous message: the Console is not properly freed after setsid when CYGWIN=notty. Programs such as inetd do not go in the background when starting from a command.com window or from the Windows "run" menu. Things are fine with CYGWIN=tty By the way, I don't understand why open_fhs is modified in the slave tty and ctty code. The only purpose I see in open_fhs is to free the console at the right time. Why should the presence of a slave tty, possibly connected to an entirely different console window, impact on the local console? (this is not a new issue). However things are not fine when building from CVS, even after cleaning the Cygwin object directory and running configure. Programs die on startup as shown below. It's related to the threadinfo stuff. Pierre (gdb) run Starting program: /usr/bin/ls.exe Program received signal SIGSEGV, Segmentation fault. [Switching to thread -189799.0xfdba3341] 0x00c9e65a in ?? () (gdb) info threads * 3 thread -189799.0xfdba3341 0x00c9e65a in ?? () 2 thread -189799.0xfd8a60f5 0xbff8a127 in KERNEL32!ExpandEnvironmentStringsW () from /c/WINDOWS/SYSTEM/KERNEL32.DLL 1 thread -189799.0xfdbcf3fd _vfprintf_r (data=0x84e650, fp=0x84e040, fmt0=0x6101df61 "cYgstd %x %x %x", ap=0x84e0c8 "\020á\204") at ../../../../../src/newlib/libc/stdio/vfprintf.c:385 (gdb) bt #0 0x00c9e65a in ?? () #1 0x610041f0 in _threadinfo::call2(unsigned long (*)(void*, void*), void*, vo d*) (func=0xc9e650, arg=0xc9e414, buf=0xc9c790) at ../../../../src/winsup/cygwin/cygtls.cc:51 #2 0x610041b8 in _threadinfo::call(unsigned long (*)(void*, void*), void*) ( func=0xc9e650, arg=0xc9e414) at ../../../../src/winsup/cygwin/cygtls.cc:44 #3 0x610f5780 in ZZ12cygheap_initE23cygheap_protect_storage () #4 0x00c9e390 in ?? () -- 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: new snapshot with some tty/WinMe fixes
On Sat, Jan 03, 2004 at 06:16:28PM -0500, Pierre A. Humblet wrote: >1) With the snapshot I can start cygwin programs fine and I have not observed >any popup. Wish I could say the same. I am seeing the popup consistently. At least now I can duplicate it. I even understand it. >2) The regression repeated before (see original mail for more details) is still there: >"However when using sh, > setsid sh -c "echo hello > /dev/tty1; /bin/sleep 10; /bin/echo there > /dev/tty" > sh and the final echo hang forever (with echo in the "O" state in ps), > and sh cannot be terminated with kill (OK from the task manager)." I could be wrong but I don't recall saying that I'd fixed that problem. >3) There is another regression that I had also observed with the previous snapshot, >but after sending my previous message: the Console is not properly freed after >setsid when CYGWIN=notty. Programs such as inetd do not go in the background when >starting from a command.com window or from the Windows "run" menu. >Things are fine with CYGWIN=tty "Go in the background" == ? >By the way, I don't understand why open_fhs is modified in the slave tty and ctty >code. The only purpose I see in open_fhs is to free the console at the right time. >Why should the presence of a slave tty, possibly connected to an entirely different >console window, impact on the local console? (this is not a new issue). You're right. This is not a new issue. It's even been discussed before. I don't know if it was in private email between me and Corinna but since you apparently haven't searched for any past discussion, I'll be lazy and assume it was discussed in cygwin-developers. 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: new snapshot with some tty/WinMe fixes
At 06:25 PM 1/3/2004 -0500, Christopher Faylor wrote: >On Sat, Jan 03, 2004 at 06:16:28PM -0500, Pierre A. Humblet wrote: >>1) With the snapshot I can start cygwin programs fine and I have not observed >>any popup. > >Wish I could say the same. I am seeing the popup consistently. At least now I >can duplicate it. I even understand it. > >>2) The regression repeated before (see original mail for more details) is still there: >>"However when using sh, >> setsid sh -c "echo hello > /dev/tty1; /bin/sleep 10; /bin/echo there > /dev/tty" >> sh and the final echo hang forever (with echo in the "O" state in ps), >> and sh cannot be terminated with kill (OK from the task manager)." > >I could be wrong but I don't recall saying that I'd fixed that problem. You are right, you said: "I tried all of the test cases that Pierre previously reported but I'm sure I missed one." So I looked for the one. >>3) There is another regression that I had also observed with the previous snapshot, >>but after sending my previous message: the Console is not properly freed after >>setsid when CYGWIN=notty. Programs such as inetd do not go in the background when >>starting from a command.com window or from the Windows "run" menu. >>Things are fine with CYGWIN=tty > >"Go in the background" == ? If you type "setsid sleep 10" in command.com, you get the prompt back immediately when CYGWIN=tty, but you have to wait 10 s if CYGWIN=notty. If you execute inetd from "Run", the window stays around. >>By the way, I don't understand why open_fhs is modified in the slave tty and ctty >>code. The only purpose I see in open_fhs is to free the console at the right time. >>Why should the presence of a slave tty, possibly connected to an entirely different >>console window, impact on the local console? (this is not a new issue). > >You're right. This is not a new issue. It's even been discussed before. I don't >know if it was in private email between me and Corinna but since you apparently >haven't searched for any past discussion, I'll be lazy and assume it was >discussed in cygwin-developers. According to the Changelog it was probably done in early March 2003 but I didn't find any relevant discussion around that date. 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: new snapshot with some tty/WinMe fixes
On Sat, Jan 03, 2004 at 07:18:07PM -0500, Pierre A. Humblet wrote: >>I could be wrong but I don't recall saying that I'd fixed that problem. > >You are right, you said: "I tried all of the test cases that Pierre >previously reported but I'm sure I missed one." So I looked for the >one. Yes, you caught me on semantics. I was trying to convey that I hoped I hadn't broken anything new. -- 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: bzip2-1.0.2 from official home page not working with Cygwin
On Saturday 03 January 2004 04:47 am, Gerrit P. Haase wrote: > There is a (small) patch included in the Cygwin source package, maybe > that helps? The library compiles fine on Linux (granted, I'm using gcc 3.2.2 there) so I would expect it to work using Cygwin. I'll track down the patch and pass it along to the bzip2 owner. -Karl -- 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: Bug in fstream code and gcc-2 package?
At 04:12 PM 1/3/2004, Gerrit P. Haase wrote: >Hallo Beman, > >I cannot reproduce it here on my NT4 SP 6a: John Maddock can't reproduce it on his system either. First, my results for the queries below are shown after your results: >$ uname -svr >CYGWIN_NT-4.0 1.5.5(0.94/3/2) 2003-09-20 16:31 CYGWIN_NT-5.1 1.5.5(0.94/3/2) 2003-09-20 16:31 >$ cygcheck -c gcc >Cygwin Package Information >Package VersionStatus >gcc 3.3.1-3OK gcc 3.3.1-3OK >$ cygcheck -c gcc-g++ >Cygwin Package Information >Package VersionStatus >gcc-g++ 3.3.1-3OK gcc-g++ 3.3.1-3OK >$ g++ fstream.cpp >$ ls >a.exe* fstream.cpp >$ ./a 2 [main] a 1228 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 327 [main] a 1228 open_stackdumpfile: Dumping stack trace to a.exe.stackdump >$ cygcheck a >Found: .\a.exe >a.exe > H:\bin\cygwin1.dll >C:\WINNT\System32\KERNEL32.dll > C:\WINNT\System32\ntdll.dll Found: .\a.exe a.exe c:\cygwin\bin\cygwin1.dll C:\WINDOWS\System32\KERNEL32.dll C:\WINDOWS\System32\ntdll.dll >$ g++ -mno-cygwin fstream.cpp In file included from /usr/local/include/c++/3.3.1/bits/locale_facets.h:166, from /usr/local/include/c++/3.3.1/bits/basic_ios.h:44, from /usr/local/include/c++/3.3.1/ios:51, from /usr/local/include/c++/3.3.1/istream:44, from /usr/local/include/c++/3.3.1/fstream:45, from fstream.cpp:1: /usr/local/include/c++/3.3.1/i686-pc-cygwin/bits/ctype_base.h:46: error: `_U' was not declared in this scope (similar errors follow; messages elided for brevity.) >$ ls >a.exe* fstream.cpp >$ ./a >$ cygcheck a >Found: .\a.exe >a.exe > C:\WINNT\System32\msvcrt.dll >C:\WINNT\System32\KERNEL32.dll > C:\WINNT\System32\ntdll.dll > >Can you run it with gdb and try to figure out what fails for you? I've never used gdb, but here goes... install... try it... For some reason I couldn't get a meaningful stack trace, but by stepping it was easy to isolate the problem. It is in the execution of the call: is.rdbuf()->in_avail() is.rdbuf() looks like it is returning the correct pointer, but in_avail() is dying. If I replace the call with a constant, say 16000, the program runs fine. Does that help? By the way, the above results hold regardless of whether the program is run from the Win XP command line or the bash command line. --Beman -- 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/
DLL vs. shared object linking behavior
I have a shared library which has undefined references to functions. On Linux I can build and use the library without problems, but when I build it as a DLL using Cygwin the undefined references are link errors. Can the Windows loader handle unresolved symbols in DLLs at runtime? Is there some magic compiler option I can use to allow this? -Karl -- 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/
cygwin's system() function
Hello,
I'm having problems getting the system() function to work correctly outside
of the cygwin environment.
for example, I compile the following file in the BASH environment using the
command
gcc systemtest.c -out systemtest.exe
int main(void)
{
return system("notepad.exe");
}
then, while I'm in the BASH enviroment, I can run systemtest.exe, and it
will open up notepad.
however, if I try to run it from the windows environment, it doesn't do
anything. It just runs and ends. no error messages or anything.
I tried a number of different absolute paths to notepad, i.e.
"c:\\windows\\system32\\notepad.exe"
"c:/windows/systems32/notepad.exe"
"/cygdrive/c/windows/system32/notepad.exe"
system returns 127 when I run it in the windows environment, with
"notepad.exe" as the parameter, and 0 when I run it in the cygwin enviroment
with "notepad.exe" as the parameter.
It returns -1 when I run it in the windows or cygwin environment, and pass
it a null value.
anyone have any ideas how to resolve this?
here is the info from cygcheck -sysinfo
--
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Sat Jan 03 20:08:46 2004
Windows XP Professional Ver 5.1 Build 2600 Service Pack 1
Path: E:\Apps\cygwin\usr\local\bin
E:\Apps\cygwin\bin
E:\Apps\cygwin\bin
E:\Apps\cygwin\usr\X11R6\bin
c:\Perl\bin\
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\NMapWin\bin
Output from E:\Apps\cygwin\bin\id.exe (nontsec)
UID: 500(JesusFreke) GID: 513(None)
513(None)
Output from E:\Apps\cygwin\bin\id.exe (ntsec)
UID: 500(JesusFreke) GID: 513(None)
513(None) 544(Administrators)
551(Backup Operators) 545(Users)
1005(Debugger Users)
SysDir: C:\WINDOWS\System32
WinDir: C:\WINDOWS
HOME = `E:\Apps\cygwin\home\JesusFreke'
MAKE_MODE = `unix'
PWD = `/usr/systemtest'
USER = `JesusFreke'
Use `-r' to scan registry
a: fd N/AN/A
c: hd NTFS 94993Mb 10% CP CS UN PA FC
d: hd NTFS 95778Mb 88% CP CS UN PA FC Huge Partition of -=|DOOM|=-
e: hd NTFS 74292Mb 56% CP CS UN PA FC Fast Bugger
f: cd CDFS 42Mb 100%CS UN X2289A0
g: cd N/AN/A
h: cd CDFS 615Mb 100%CS UN MSDVVSD3
E:\Apps\cygwin / system binmode
E:\Apps\cygwin\bin /usr/bin system binmode
E:\Apps\cygwin\lib /usr/lib system binmode
. /cygdrive system binmode,cygdrive
Not Found: awk
Found: E:\Apps\cygwin\bin\bash.exe
Found: E:\Apps\cygwin\bin\cat.exe
Found: E:\Apps\cygwin\bin\cp.exe
Found: E:\Apps\cygwin\bin\cpp.exe
Found: E:\Apps\cygwin\bin\find.exe
Found: E:\Apps\cygwin\bin\gcc.exe
Found: E:\Apps\cygwin\bin\gdb.exe
Found: E:\Apps\cygwin\bin\grep.exe
Found: E:\Apps\cygwin\bin\ld.exe
Found: E:\Apps\cygwin\bin\ls.exe
Found: E:\Apps\cygwin\bin\make.exe
Found: E:\Apps\cygwin\bin\mv.exe
Found: E:\Apps\cygwin\bin\rm.exe
Found: E:\Apps\cygwin\bin\sed.exe
Found: E:\Apps\cygwin\bin\sh.exe
Found: E:\Apps\cygwin\bin\tar.exe
949k 2003/09/20 C:\WINDOWS\System32\cygwin1.dll
Cygwin DLL version info:
DLL version: 1.5.5
DLL epoch: 19
DLL bad signal mask: 19005
DLL old termios: 5
DLL malloc env: 28
API major: 0
API minor: 94
Shared data: 3
DLL identifier: cygwin1
Mount registry: 2
Cygnus registry name: Cygnus Solutions
Cygwin registry name: Cygwin
Program options name: Program Options
Cygwin mount registry name: mounts v2
Cygdrive flags: cygdrive flags
Cygdrive prefix: cygdrive prefix
Cygdrive default prefix:
Build date: Sat Sep 20 16:31:15 EDT 2003
CVS tag: cr-0x9b
Shared id: cygwin1S3
61k 2003/08/09 E:\Apps\cygwin\bin\cygbz2-1.dll
14k 2003/08/10 E:\Apps\cygwin\bin\cygcharset-1.dll
22k 2003/10/17 E:\Apps\cygwin\bin\cygcygipc-2.dll
132k 2003/07/12 E:\Apps\cygwin\bin\cygexpat-0.dll
35k 2002/01/09 E:\Apps\cygwin\bin\cygform6.dll
361k 2003/10/25 E:\Apps\cygwin\bin\cygfreetype-6.dll
28k 2003/07/20 E:\Apps\cygwin\bin\cyggdbm-3.dll
30k 2003/08/11 E:\Apps\cygwin\bin\cyggdbm-4.dll
19k 2003/03/22 E:\Apps\cygwin\bin\cyggdbm.dll
15k 2003/07/20 E:\Apps\cygwin\bin\cyggdbm_compat-3.dll
15k 2003/08/11 E:\Apps\cygwin\bin\cyggdbm_compat-4.dll
69k 2003/08/10 E:\Apps\cygwin\bin\cyggettextlib-0-12-1.dll
12k 2003/08/10 E:\Apps\cygwin\bin\cyggettextpo-0.dll
134k 2003/08/10 E:\Apps\cygwin\bin\cyggettextsrc-0-12-1.dll
17k 2001/06/28 E:\Apps\cygwin\bin\cyghistory4.dll
29k 2003/08/10 E:\Apps\cygwin\bin\cyghistory5.dll
958k 2003/08/10 E:\Apps\cygwin\bin\cygiconv-2.dll
22k 2001/12/13 E:\Apps\cygwin\bin\cygintl-1.dll
37k 2003/08/10 E:\Apps\cygwin\bin\cygintl-2.dll
21k 2001/06/20 E:\Apps\cygwin\bin\cygintl.dll
20k 2002/01/09 E:\Apps\cygwin\bin\cygmenu6.dll
175k 2002/01/09 E:\Apps\cygwin\bin\cygncurses++6.dll
202k 2002/01/09 E:\Apps\cygwin\bin\cygncurse
Re: new snapshot with some tty/WinMe fixes
From: Christopher Faylor <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: new snapshot with some tty/WinMe fixes Date: Sat, 3 Jan 2004 19:41:33 -0500 On Sat, Jan 03, 2004 at 07:18:07PM -0500, Pierre A. Humblet wrote: >>I could be wrong but I don't recall saying that I'd fixed that problem. > >You are right, you said: "I tried all of the test cases that Pierre >previously reported but I'm sure I missed one." So I looked for the >one. Yes, you caught me on semantics. I was trying to convey that I hoped I hadn't broken anything new. Chris...you are so kind (sob sob), I just don't know what to say...It just makes me feel so...Oh I don't know what to say (sob sob). -- 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/ _ Have fun customizing MSN Messenger learn how here! http://www.msnmessenger-download.com/tracking/reach_customize -- 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's system() function RESOLVED
nevermind, I finally found the solution in an earlier post in this
newsgroup. I didn't have cygwin's bin directory in my window's PATH.
JesusFreke
"news.gmane.org" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello,
>
> I'm having problems getting the system() function to work correctly
outside
> of the cygwin environment.
>
> for example, I compile the following file in the BASH environment using
the
> command
>
> gcc systemtest.c -out systemtest.exe
>
> int main(void)
> {
> return system("notepad.exe");
> }
>
> then, while I'm in the BASH enviroment, I can run systemtest.exe, and it
> will open up notepad.
>
> however, if I try to run it from the windows environment, it doesn't do
> anything. It just runs and ends. no error messages or anything.
>
> I tried a number of different absolute paths to notepad, i.e.
>
> "c:\\windows\\system32\\notepad.exe"
> "c:/windows/systems32/notepad.exe"
> "/cygdrive/c/windows/system32/notepad.exe"
>
> system returns 127 when I run it in the windows environment, with
> "notepad.exe" as the parameter, and 0 when I run it in the cygwin
enviroment
> with "notepad.exe" as the parameter.
>
> It returns -1 when I run it in the windows or cygwin environment, and pass
> it a null value.
>
> anyone have any ideas how to resolve this?
>
>
> here is the info from cygcheck -sysinfo
>
> --
> Cygwin Win95/NT Configuration Diagnostics
> Current System Time: Sat Jan 03 20:08:46 2004
>
> Windows XP Professional Ver 5.1 Build 2600 Service Pack 1
>
> Path: E:\Apps\cygwin\usr\local\bin
> E:\Apps\cygwin\bin
> E:\Apps\cygwin\bin
> E:\Apps\cygwin\usr\X11R6\bin
> c:\Perl\bin\
> c:\WINDOWS\system32
> c:\WINDOWS
> c:\WINDOWS\System32\Wbem
> c:\Program Files\NMapWin\bin
>
> Output from E:\Apps\cygwin\bin\id.exe (nontsec)
> UID: 500(JesusFreke) GID: 513(None)
> 513(None)
>
> Output from E:\Apps\cygwin\bin\id.exe (ntsec)
> UID: 500(JesusFreke) GID: 513(None)
> 513(None) 544(Administrators)
> 551(Backup Operators) 545(Users)
> 1005(Debugger Users)
>
> SysDir: C:\WINDOWS\System32
> WinDir: C:\WINDOWS
>
> HOME = `E:\Apps\cygwin\home\JesusFreke'
> MAKE_MODE = `unix'
> PWD = `/usr/systemtest'
> USER = `JesusFreke'
>
> Use `-r' to scan registry
>
> a: fd N/AN/A
> c: hd NTFS 94993Mb 10% CP CS UN PA FC
> d: hd NTFS 95778Mb 88% CP CS UN PA FC Huge Partition
of -=|DOOM|=-
> e: hd NTFS 74292Mb 56% CP CS UN PA FC Fast Bugger
> f: cd CDFS 42Mb 100%CS UN X2289A0
> g: cd N/AN/A
> h: cd CDFS 615Mb 100%CS UN MSDVVSD3
>
> E:\Apps\cygwin / system binmode
> E:\Apps\cygwin\bin /usr/bin system binmode
> E:\Apps\cygwin\lib /usr/lib system binmode
> . /cygdrive system binmode,cygdrive
>
> Not Found: awk
> Found: E:\Apps\cygwin\bin\bash.exe
> Found: E:\Apps\cygwin\bin\cat.exe
> Found: E:\Apps\cygwin\bin\cp.exe
> Found: E:\Apps\cygwin\bin\cpp.exe
> Found: E:\Apps\cygwin\bin\find.exe
> Found: E:\Apps\cygwin\bin\gcc.exe
> Found: E:\Apps\cygwin\bin\gdb.exe
> Found: E:\Apps\cygwin\bin\grep.exe
> Found: E:\Apps\cygwin\bin\ld.exe
> Found: E:\Apps\cygwin\bin\ls.exe
> Found: E:\Apps\cygwin\bin\make.exe
> Found: E:\Apps\cygwin\bin\mv.exe
> Found: E:\Apps\cygwin\bin\rm.exe
> Found: E:\Apps\cygwin\bin\sed.exe
> Found: E:\Apps\cygwin\bin\sh.exe
> Found: E:\Apps\cygwin\bin\tar.exe
>
> 949k 2003/09/20 C:\WINDOWS\System32\cygwin1.dll
> Cygwin DLL version info:
> DLL version: 1.5.5
> DLL epoch: 19
> DLL bad signal mask: 19005
> DLL old termios: 5
> DLL malloc env: 28
> API major: 0
> API minor: 94
> Shared data: 3
> DLL identifier: cygwin1
> Mount registry: 2
> Cygnus registry name: Cygnus Solutions
> Cygwin registry name: Cygwin
> Program options name: Program Options
> Cygwin mount registry name: mounts v2
> Cygdrive flags: cygdrive flags
> Cygdrive prefix: cygdrive prefix
> Cygdrive default prefix:
> Build date: Sat Sep 20 16:31:15 EDT 2003
> CVS tag: cr-0x9b
> Shared id: cygwin1S3
>
>61k 2003/08/09 E:\Apps\cygwin\bin\cygbz2-1.dll
>14k 2003/08/10 E:\Apps\cygwin\bin\cygcharset-1.dll
>22k 2003/10/17 E:\Apps\cygwin\bin\cygcygipc-2.dll
> 132k 2003/07/12 E:\Apps\cygwin\bin\cygexpat-0.dll
>35k 2002/01/09 E:\Apps\cygwin\bin\cygform6.dll
> 361k 2003/10/25 E:\Apps\cygwin\bin\cygfreetype-6.dll
>28k 2003/07/20 E:\Apps\cygwin\bin\cyggdbm-3.dll
>30k 2003/08/11 E:\Apps\cygwin\bin\cyggdbm-4.dll
>19k 2003/03/22 E:\Apps\cygwin\bin\cyggdbm.dll
>15k 2003/07/20 E:\Apps\cygwin\bin\cyggdbm_compat-3.dll
>15k 2003/08/11 E:\Apps\cygwin\bin\cyggdbm_compat-4.dll
>69k 2003/08/10 E:\Apps\cygwin\bin\cyggettextlib-0-12-1.dll
>12k 2003/08/10 E:\Apps\cygwin\bin\cyggettextpo-0.dll
> 134k 2003/08/10 E:\Apps\cygwin\b
