Initialisation with data from dll-libraries
Asking for help. I am porting a tool to implement interpreters from Linux to Windows/Cygwin, and have succeeded with a statically linked version. Interpreters depend on several libraries and use a dispatch table with pointers to functions from the libraries. The statically linked port has been tested succesfully. With gcc it is possible to build dll-versions of the libraries (i.e. pairs of cygXXX.dll and libXXX.dll.a). An application can be built, if there is no dispatch table, but when I try to build an interpreter the resulting dispatch table contains just null references. The terminology related to dll is rather confusing to me as a novice user of these. After having looked into various descriptions I am left with a number of questions: . The following command (outline) has been used: $(CC) -o demo */glue.o dispatch.o \ -Wl,--enable-auto-import \ -Wl,--no-whole-archive $(LFLAGS) No error or warning arises, and the interpreter starts to ask for input as expected, but the first attempt to use the dispatch table leads to a segmentation fault. Am I missing some options here? . Will a *.def file be helpful (or: required) in order to have the linker initialise the dispatch table correctly? . Must I use dlltool rather than just gcc to build the libraries with enough information to get the dispatch table initialised? Please help me if you can. Jørgen -- 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/
socket() hanged on -- CYGWIN5.0(1.3.22)
When I call socket(AF_INET,SOCK_STREAM,0), my program hanged on here. Then I use strace execute my programe and report all cygwin DLL output. Followint is the result of strace. Some signal information is print after calling socket. Why and how can I solve it? When I call the progame in windows XP which means CYGWIN5.1, the program do well. 101 1031277 [win] rapgen 3316 kill_worker: 0 = kill_worker (3316, 14) 870 1032147 [main] rapgen 3316 set_process_mask: not calling sig_dispatch_pending. sigtid 0xBDC current 0xAE8 228 1032375 [main] rapgen 3316 call_signal_handler_now: sa_flags 0x0 123 1032498 [main] rapgen 3316 reset_signal_arrived: reset signal_arrived 119 1032617 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 2000 1003 1033620 [main] rapgen 3316 set_process_mask: old mask = 2000, new mask = 2000 216 1033836 [main] rapgen 3316 set_process_mask: not calling sig_dispatch_pending. sigtid 0xBDC current 0xAE8 124 1033960 [main] rapgen 3316 set_process_mask: old mask = 2000, new mask = 0 133 1034093 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 2000 119 1034212 [main] rapgen 3316 set_process_mask: old mask = 2000, new mask = 0 112 1034324 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 0 109 1034433 [main] rapgen 3316 set_process_mask: not calling sig_dispatch_pending. sigtid 0xBDC current 0xAE8 113 1034546 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 2000 114 1034660 [main] rapgen 3316 set_process_mask: old mask = 2000, new mask = 0 127 1034787 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 0 109 1034896 [main] rapgen 3316 set_process_mask: not calling sig_dispatch_pending. sigtid 0xBDC current 0xAE8 114 1035010 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 2000 161 1035171 [main] rapgen 3316 set_process_mask: old mask = 2000, new mask = 0 112 1035283 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 0 110 1035393 [main] rapgen 3316 set_process_mask: not calling sig_dispatch_pending. sigtid 0xBDC current 0xAE8 114 1035507 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 2000 112 1035619 [main] rapgen 3316 set_process_mask: old mask = 2000, new mask = 0 110 1035729 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 0 108 1035837 [main] rapgen 3316 set_process_mask: not calling sig_dispatch_pending. sigtid 0xBDC current 0xAE8 132 1035969 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 2000 124 1036093 [main] rapgen 3316 set_process_mask: old mask = 2000, new mask = 0 144 1036237 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 2000 118 1036355 [main] rapgen 3316 set_process_mask: old mask = 2000, new mask = 0 116 1036471 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 0 111 1036582 [main] rapgen 3316 set_process_mask: not calling sig_dispatch_pending. sigtid 0xBDC current 0xAE8 114 1036696 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 2000 112 1036808 [main] rapgen 3316 set_process_mask: old mask = 2000, new mask = 0 115 1036923 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 0 111 1037034 [main] rapgen 3316 set_process_mask: not calling sig_dispatch_pending. sigtid 0xBDC current 0xAE8 779 1037813 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 2000 145 1037958 [main] rapgen 3316 set_process_mask: old mask = 2000, new mask = 0 139 1038097 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 0 117 1038214 [main] rapgen 3316 set_process_mask: not calling sig_dispatch_pending. sigtid 0xBDC current 0xAE8 114 1038328 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 2000 114 1038442 [main] rapgen 3316 set_process_mask: old mask = 2000, new mask = 0 115 1038557 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 0 114 1038671 [main] rapgen 3316 set_process_mask: not calling sig_dispatch_pending. sigtid 0xBDC current 0xAE8 114 1038785 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 2000 113 1038898 [main] rapgen 3316 set_process_mask: old mask = 2000, new mask = 0 115 1039013 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 0 122 1039135 [main] rapgen 3316 set_process_mask: not calling sig_dispatch_pending. sigtid 0xBDC current 0xAE8 112 1039247 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 2000 112 1039359 [main] rapgen 3316 set_process_mask: old mask = 2000, new mask = 0 114 1039473 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 0 111 1039584 [main] rapgen 3316 set_process_mask: not calling sig_dispatch_pending. sigtid 0xBDC current 0xAE8 112 1039696 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 2000 112 1039808 [main] rapgen 3316 set_process_mask: old mask = 2000, new mask = 0 114 1039922 [main] rapgen 3316 set_process_mask: old mask = 0, new mask = 0 110 1040032 [main] rapg
popen() fails after 256 successful calls
Hello, I have two directories, both with ~4k files in them. For each
directory I needed to calculate a SHA1 checksum on each file and store them
in a table and then do some comparisons. I wrote a C++ program for this but
I noticed popen() (which I use to invoke sha1sum.exe to calculate the
checksum) would fail after 256 successful calls with the error "Resource
temporarily unavailable". I rewrote the program in pure C and kept just the
directory scanning/popen() part and tried a few directories but still the
same error. Attached is the source for the C program, Makefile to build it
and cygcheck output.
Also, when I tried the program on another directory, one that had a file
with an & in the name, the program behaved weirdly, cutting of the name at
the &. But that is a different, less urgent, problem.
Any ideas on how I can debug this further?
/ E
begin 666 Makefile.dat
M0T,@/2!G8V,*0T9,04=3([EMAIL PROTECTED];&[EMAIL
PROTECTED]<@+6<@+4\P("UC"DQ$1DQ!1U,@
M/2 M;R D*$5814,I"D5814,@/2!P97)F;W)M7V-H96-K("0H3$1&
M3$%'4RD*"B4N;SH@)2YC"@DD*$-#*2 D*$-&3$%'4RD@)#P*"[EMAIL PROTECTED])
H<[EMAIL PROTECTED]@)"A/0DI%0U13*2 D*$5814,I("I^("HN6=W:[EMAIL PROTECTED])A=&EO;B!$:6%G;F]S=&EC[EMAIL PROTECTED]&[EMAIL PROTECTED]($%P6=W:6Y<=7-R7&QO8V%L7&)I;@T*"4,Z
M7&-Y9W=I;EQB:6X-"@E#.EQC>6=W:6Y<8FEN#0H)0SI<8WEG=VEN7'5S7-T96TS,@T*5VEN1&ER
M.B!#.EQ724Y$3U=3#0H-"E5315(@/2 G;6EK865L)PT*4%=$(#T@)R]H;VUE
M+VUI:V%E;"]C;V1I;F'9T+6-Y9W=I;BUN871I=F4G#0I04D]#15-33U)?241%3E1)
M1DE%4B ]("[EMAIL PROTECTED]:6QY(#$U($UO9&5L(#0W(%-T97!P:6YG(#(L($%U
M=&AE;G1I8T%-1"<-"E=)3D1)4B ]("=#.EQ724Y$3U=3)PT*5E,X,$-/34Y4
M3T],4R ]("=#.EQV:7-U86Q?'!M)PT*7R ]("6=C:&5C:R<-"E!/
M4TE83%E?0T]24D5#5" ]("6=N=7,@4V]L=71I;VYS#0I(2T597T-54E)%3E1?55-%4EQ3;V9T
M=V%R95Q#>6=N=7,@4V]L=71I;VYS7$-Y9W=I;@T*2$M%65]#55)214Y47U53
M15)<4V]F='=A6=W:6Y<;6]U;G1S('8R
M#0I(2T597T-54E)%3E1?55-%4EQ3;V9T=V%R95Q#>6=N=7,@4V]L=71I;VYS
M7$-Y9W=I;EQ0'1S7"YC>6=N=7,-"DA+15E?0U524D5.5%]54T527%-O9G1W
M87)E7$UI8W)O'1S7"YC>6=N=7-<3W!E;E=I=&A,:7-T#0I(2T597TQ/0T%,7TU!
M0TA)3D5<4T]&5%=!4D5<0WEG;G5S(%-O;'5T:6]N6=W
M:6Y<;6]U;G1S('8R#0H@("AD969A=6QT*2 ]("6=W:6XG#0H@(&9L86=S(#T@,'@P,# P
M,# P80T*2$M%65],3T-!3%]-04-(24Y%7%-/1E1705)%7$-Y9VYU# P,# P,#!A#0I(2T59
M7TQ/0T%,7TU!0TA)3D5<4T]&5%=!4D5<0WEG;G5S(%-O;'5T:6]N6=W
M:6Y<;6]U;G1S('8R7"]U6=W
M:6XO;&EB)PT*("!F;&%G6=N=7,@4V]L=71I;VYS7$-Y9W=I;EQ07-T96T@(&)I;FUO9&4-
M"D,Z7&-Y9W=I;B]B:6X@("]U6=W:6XO;&EB(" O=7-R+VQI8B @('-Y7-T96T@(&)I;FUO9&4L8WEG9')I
M=F4-"@T*1F]U;F0Z($,Z7&-Y9W=I;EQB:6Y<87=K+F5X90T*1F]U;F0Z($,Z
M7&-Y9W=I;EQB:6Y<8F%S:"YE>&4-"D9O=6YD.B!#.EQC>6=W:6Y<8FEN7&-A
M="YE>&4-"D9O=6YD.B!#.EQC>6=W:6Y<8FEN7&-P+F5X90T*1F]U;F0Z($,Z
M7&-Y9W=I;EQB:6Y<8W!P+F5X90T*3F]T($9O=6YD.B!C&4-"D9O=6YD.B!#.EQC>6=W:6Y<
M8FEN7&MI;&PN97AE#0I&;[EMAIL PROTECTED]<8WEG=VEN7&)I;EQL9"YE>&4-"D9O
M=6YD.B!#.EQC>6=W:6Y<8FEN7&QS+F5X90T*1F]U;F0Z($,Z7&-Y9W=I;EQB
M:6Y<;6%K92YE>&4-"D9O=6YD.B!#.EQC>6=W:6Y<8FEN7&UV+F5X90T*3F]T
M($9O=6YD.B!P871C: T*1F]U;F0Z($,Z7&-Y9W=I;EQB:6Y<<&5R;"YE>&4-
M"D9O=6YD.B!#.EQC>6=W:6Y<8FEN7')M+F5X90T*1F]U;F0Z($,Z7&-Y9W=I
M;EQB:6Y<6=B>C(M,2YD;&[EMAIL PROTECTED]7,]-"XP#0H@(" @(" @(" @(" @(" @(" B8WEG8GHR+3$N9&QL
M(B!V,"XP('1S/3(P,#4O-R\Y(#6=C:&%R6=C;VUP9F%C92TP+F1L;" M(&]S/30N,"!I;6<]
M,2XP('-Y6=C;VUP9F%C92TP
M+F1L;"(@=C N,"!T6=W:6Y<8FEN7&-Y9V-R>7!T+3 N9&QL("T@;W,]-"XP(&EM
M9STQ+C @7!T+3 N
M9&QL(B!V,"XP('1S/3(P,#,O,3 O,[EMAIL PROTECTED](#$Q,#AK(#(P,#4O,3 O
M,3<@0SI<8WEG=VEN7&)I;EQC>6=C7!T
M;RTP+CDN-RYD;&PB('8P+C @=',],C P-2\Q,"\Q-R Q,[EMAIL PROTECTED](#$P-#=K
M(#(P,#4O,3 O,[EMAIL PROTECTED]<8WEG=VEN7&)I;EQC>6=C7!T;RTP+CDN."YD;&PB('8P+C @=',],C P-2\Q,"\Q,2 Q-#HT
M-PT*(" X.35K(#(P,#0O,#0O,C@@0SI<8WEG=VEN7&)I;EQC>6=D8BTT+C(N
M9&QL("T@;W,]-"XP(&EM9STQ+C @6=E>'!A="TP
M+F1L;" M(&]S/30N,"!I;6<],2XP('-Y6=E>'!A="TP+F1L;"(@=C N,"!T6=W:6Y<8FEN7&-Y9V9O;G1C;VYF
M:67,]-"XP#0H@(" @(" @(" @
M(" @(" @(" B8WEG9F]N=&-O;F9I9RTQ+F1L;"(@=C N,"!T6=F
M;W)[EMAIL PROTECTED]&QL("T@;W,]-"XP(&EM9STQ+C @6=F6=F6=W:6Y<8FEN7&-Y9V=D8FTM,RYD;&[EMAIL PROTECTED]7,]-"XP#0H@(" @(" @(" @(" @(" @(" B8WEG9V1B;2TS+F1L;"(@
M=C N,"!T6=G9&)M+30N9&QL("T@;W,]-"XP(&EM9STQ+C @6=W:6Y<8FEN7&-Y9V=L:6(M,2TR+3 N9&QL("T@;W,]-"XP(&EM
M9STQ+C @6=W:6Y<8FEN7&-Y9V=M;V1U;&4M,2TR+3 N9&QL("T@;W,]
M-"XP(&EM9STQ+C @6=W:6Y<8FEN7&-Y9V=M<"TS+F1L;" M(&]S
M/30N,"!I;6<],2XP('-Y6=G
M;7 M,RYD;&PB('8P+C @=',],C P-"\Q,"\Q-B Y.C0P#0H@(#(X.&L@,C P
M-"\Q,"\Q-B!#.EQC>6=W:6Y<8FEN7&-Y9V=M<'AX+3,N9&QL("T@;W,]-"XP
M(&EM9STQ+C @6=G=&AR96%D+3$M,BTP+F1L;" M(&]S
M/30N,"!I;6<],2XP('-Y6=G
M=&AR96%D+3$M,BTP+F1L;"(@=C N,"!T6=H:7-T;W)Y-"YD;&P@
M+2!O7,]-"XP#0H@(" @(" @(" @(" @(" @(" B
M8WEG:&ES=&]R>30N9&QL(B!V,"XP('1S/3(P,#$O,2\W(#4Z,S0-"B @(#(Y
M:R R,# S+S X+S$P($,Z7&-Y9W=I;EQB:6Y<8WEG:&ES=&]R>34N9&QL("T@
M;W,]-"XP(&EM9STQ+C @6=H:7-T;W)Y-BYD;&[EMAIL PROTECTED]
M7,]-"XP#0H@(" @(" @(" @(" @(" @(" B8WEG
M:&ES=&]R>38N9&QL(B!V,"XP('1S/3(P,#8O,B\Q." W.C S#0H@(#DT-VL@
M,C P-2\Q,2\R,"!#.EQC>6=W:6Y<8FEN7&-Y9VEC;VYV+3(N9&QL("T@;W,]
M-"XP(&EM9STQ+C @6=I;G1L+3$N9&QL("T@;W,]-"XP
M(&EM9STQ+C @6=W:6Y<8FEN
M7&-Y9VIP967,]-"XP#0H@(" @
M(" @(" @(" @(" @(" B8WEG:G!E9S9B+
Re: popen() fails after 256 successful calls
Eric Lilja wrote: Hello, I have two directories, both with ~4k files in them. For each directory I needed to calculate a SHA1 checksum on each file and store them in a table and then do some comparisons. I wrote a C++ program for this but I noticed popen() (which I use to invoke sha1sum.exe to calculate the checksum) would fail after 256 successful calls with the error "Resource temporarily unavailable". I rewrote the program in pure C and kept just the directory scanning/popen() part and tried a few directories but still the same error. Attached is the source for the C program, Makefile to build it and cygcheck output. I believe you should use pclose, not fclose, to close the stream returned by popen. Regards, Robert -- 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: Initialisation with data from dll-libraries
Jørgen Steensgaard-Madsen wrote: Asking for help. I am porting a tool to implement interpreters from Linux to Windows/Cygwin, and have succeeded with a statically linked version. Interpreters depend on several libraries and use a dispatch table with pointers to functions from the libraries. The statically linked port has been tested succesfully. With gcc it is possible to build dll-versions of the libraries (i.e. pairs of cygXXX.dll and libXXX.dll.a). An application can be built, if there is no dispatch table, but when I try to build an interpreter the resulting dispatch table contains just null references. The terminology related to dll is rather confusing to me as a novice user of these. After having looked into various descriptions I am left with a number of questions: . The following command (outline) has been used: $(CC) -o demo */glue.o dispatch.o \ -Wl,--enable-auto-import \ -Wl,--no-whole-archive $(LFLAGS) No error or warning arises, and the interpreter starts to ask for input as expected, but the first attempt to use the dispatch table leads to a segmentation fault. Am I missing some options here? . Will a *.def file be helpful (or: required) in order to have the linker initialise the dispatch table correctly? . Must I use dlltool rather than just gcc to build the libraries with enough information to get the dispatch table initialised? Please help me if you can. You haven't said where the dispatch table is or how it is supposed to filled in. Are you using dlopen/dlsym or is there another mechanism in play here to find the function pointers that are put into this table? If it's the former, I don't see an obvious reason why the pointers couldn't be filled in, unless the DLL with them cannot be found. But you should know if this is the case, unless you're not checking for errors returned. I can't imagine that a *.def file or direct utilization of dlltool would be helpful in your case, since these both allow references to be resolved at link time, which doesn't appear to be your issue at all. So I think you'll need to provide more details (perhaps a small example) of how what you're doing is supposed to work before more help can be given. -- 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/
ls displays nothing - 3/29 snapshot
I installed the 3/29 cygwin1.dll snapshot yesterday on a test windows 2000 box. Many (all?) of our cron jobs ran normally Sunday morning. Today, though, the output of 'ls' or 'ls -l' from an interactive bash session was always nothing. I've reverted back to the released cygwin1.dll, and ls is working again. Sorry for lack of details; not sure at what point the problem started showing up. -- Tom -- 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/
how to create a syslog-ng pidfile
My syslog-ng on Cygwin does not have an associated /var/run/syslog-ng.pid file. I'd like to have this as an aid to rotating the logs. To generate a pidfile for syslog-ng, should I try the -p switch to syslog-ng, (i.e. using the -a argument to cygrunsrv) or the -x argument to cygrunsrv? Or, will neither of these work? The /bin/syslog-ng-config script passes -F on to syslog-ng already. I'm thinking this is the reason a pidfile is not naturally written, and that passing -p will also have no effect? I'm also wondering, since René correctly warned me against editing the registry, how would I change the way my existing service works? Is the correct way to use cygrunsrv -R syslog-ng to remove the service, then construct a new cygrunsrv -I command with the appropriate arguments to install it? I'm not seeing this guideline in the cygrunsrv.README file explicitly, but I confess that I'm losing track of all the things I've read recently. Thanks for your attention and advice, Bryan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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: Initialisation with data from dll-libraries
Larry Hall (Cygwin cygwin.com> writes: > > Jørgen Steensgaard-Madsen wrote: > > Asking for help. > > You haven't said where the dispatch table is or how it is supposed to filled > in. First of all, thanks for reacting so promptly. The dispatch table is an array of pointers in a C-program file to be linked against the libraries. Initialised is expressed as a usual array declaration initialised with individual entries given as &some_function where some_function is declared as extern in the same file. This methods works nicely with static linkage, and also with dynamic linkage on a Linux box. Jørgen -- 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: ls displays nothing - 3/29 snapshot
On Sun, Apr 02, 2006 at 02:37:22PM -0500, Tom Rodman wrote: >I installed the 3/29 cygwin1.dll snapshot yesterday on a test windows >2000 box. Many (all?) of our cron jobs ran normally Sunday morning. >Today, though, the output of 'ls' or 'ls -l' from an interactive bash >session was always nothing. I've reverted back to the released >cygwin1.dll, and ls is working again. > >Sorry for lack of details; not sure at what point the problem started >showing up. That's ok. Minus any details, we'll just assume that you've done something wrong and ignore the problem. 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: ls displays nothing - 3/29 snapshot
On Sun 4/2/06 16:43 EDT cygwin@cygwin.com wrote: > On Sun, Apr 02, 2006 at 02:37:22PM -0500, Tom Rodman wrote: > >I installed the 3/29 cygwin1.dll snapshot yesterday on a test windows > >2000 box. Many (all?) of our cron jobs ran normally Sunday morning. > >Today, though, the output of 'ls' or 'ls -l' from an interactive bash > >session was always nothing. I've reverted back to the released > >cygwin1.dll, and ls is working again. > > > >Sorry for lack of details; not sure at what point the problem started > >showing up. > > That's ok. Minus any details, we'll just assume that you've done > something wrong and ignore the problem. I have a scroll log of all the shell commands I did on Sat/Sun, and logs from the cron jobs. Will post if I find anything helpful - so far nothing out of the ordinary shows up in STDERR; I'll go over the logs again .. -- Tom -- 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: gcc-compiled CGI + Windoze Apache = Error 500
On 01 April 2006 18:03, cshepard wrote:
> I compile the following code thusly: gcc -o hw.cgi hw.c
>
> #include
> int main(void) {
> printf("Content-type: text/html\n\n");
> printf("HW");
> exit(0);
> }
Gets you two genuine \ns.
> #!c:/Python24/python.exe
The 'doze native version.
> print "Content-type: text/html\n\n"
Gets you two CRLFs. Which is what the HTTP spec requires.
That's guesswork on my part, I don't have an apache install myself.
cheers,
DaveK
--
Can't think of a witty .sigline today
--
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: gcc-compiled CGI + Windoze Apache = Error 500
Dave Korn wrote:
> On 01 April 2006 18:03, cshepard wrote:
>
>> I compile the following code thusly: gcc -o hw.cgi hw.c
>>
>> #include
>> int main(void) {
>> printf("Content-type: text/html\n\n");
>> printf("HW");
>> exit(0);
>> }
>
> Gets you two genuine \ns.
>
>> #!c:/Python24/python.exe
>
> The 'doze native version.
>
>> print "Content-type: text/html\n\n"
>
> Gets you two CRLFs. Which is what the HTTP spec requires.
>
> That's guesswork on my part, I don't have an apache install myself.
It's 100% correct.
Under Unix, using perl, I had to do this:
print "Content-type: text/plain\r\n\r\n";
to get the required result. Under Cygwin it should be the same.
--
René Berber
--
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/
Spawnvp on pwd.exe and mkdir.exe fails
I have a simple C++ file I am using to spawn pwd.exe and mkdir.exe. These are
causing stackdumps. Can anyone help me resolve this? ls.exe does not cause a
stackdump.
The same C++ file compiles using Visual Studio and the output is as expected.
In particular on Windows:
pid=1996
/cygdrive/e/tempprojects/pwd/Debug
done
And under cygwin:
pid=5860
(pwd.exe.stackdump written)
done
Here's my program:
#include
#include
int main()
{
char* argv[] = {"pwd.exe", 0};
int pid = spawnvp( _P_NOWAIT, argv[0], argv );
printf("pid=%d\n",pid);
int termstat;
cwait( &termstat, pid, WAIT_CHILD );
printf("done\n");
return 0;
}
--
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: ls displays nothing - 3/29 snapshot
On Sun 4/2/06 15:59 CDT cygwin@cygwin.com wrote: > On Sun 4/2/06 16:43 EDT cygwin@cygwin.com wrote: > > On Sun, Apr 02, 2006 at 02:37:22PM -0500, Tom Rodman wrote: > > >I installed the 3/29 cygwin1.dll snapshot yesterday on a test windows > > >2000 box. Many (all?) of our cron jobs ran normally Sunday morning. > > >Today, though, the output of 'ls' or 'ls -l' from an interactive bash > > >session was always nothing. I've reverted back to the released > > >cygwin1.dll, and ls is working again. > > > > > >Sorry for lack of details; not sure at what point the problem started > > >showing up. > > > > That's ok. Minus any details, we'll just assume that you've done > > something wrong and ignore the problem. > > I have a scroll log of all the shell commands I did on Sat/Sun, and > logs from the cron jobs. Will post if I find anything helpful - so far > nothing out of the ordinary shows up in STDERR; I'll go over the logs > again .. The problem happens immediately for me with the 3/29 snapshot: /etc $ uname -a CYGWIN_NT-5.0 OurServer108 1.5.20s(0.155/4/2) 20060329 23:02:10 i686 Cygwin /etc $ tail -1 passwd sshd:unused_by_nt/2000/xp:1003:513:sshd privsep,U-OurServer108\sshd,S-1-5-21-1085031214-1409082233-839522115-1003:/var/empty:/bin/false /etc $ wc -l passwd 343 passwd /etc $ /bin/ls -l passwd /etc $ Cygwin Configuration Diagnostics Current System Time: Sun Apr 02 20:43:22 2006 Windows 2000 Advanced Server Ver 5.0 staffuser2 2195 Service Pack 4 Running in Terminal Service session Path: i:\tcm\user\staffuser2\bin c:\aut\cyg\bin c:\aut\m c:\aut\ulb i:\tcm\adm\bin\sys i:\tcm\adm\bin\app c:\aut\cyg\contrib\bin c:\Program Files\EMC\PowerPath\ c:\bcm63\bin c:\bcm63\jre\bin c:\bcm63\bin\util c:\WINNT\system32 c:\WINNT c:\WINNT\System32\Wbem c:\Program Files\Resource Kit\ c:\Program Files\Support Tools\ c:\PROGRA~1\BMCSOF~1\common\globalc\bin\Windows-x86 c:\Progra~1\tivoli\tsm\baclient c:\HPOV\bin c:\HPOV\bin\OpC . Output from c:\aut\cyg\bin\id.exe (nontsec) UID: 15776(staffuser2) GID: 16027(XYZ_ES_STAFF) 544(Administrators) 19968(ABC_NA-DOMxx0-tcm-Users-A) 10513(Domain Users) 1005(Informix-Admin) 16025(XYZ_BLD_MGR) 16027(XYZ_ES_STAFF) 16024(XYZ_Users)545(Users) Output from c:\aut\cyg\bin\id.exe (ntsec) UID: 15776(staffuser2) GID: 16027(XYZ_ES_STAFF) 544(Administrators) 19968(ABC_NA-DOMxx0-tcm-Users-A) 10513(Domain Users) 1005(Informix-Admin) 16025(XYZ_BLD_MGR) 16027(XYZ_ES_STAFF) 16024(XYZ_Users)545(Users) SysDir: C:\WINNT\system32 WinDir: C:\WINNT USER = 'staffuser2' PWD = '/' CYGWIN = 'binmode tty ntsec smbntsec' HOME = '/user/staffuser2' MAKE_MODE = 'UNIX' rv = '/adm/backup/recovery' HOMEPATH = '\Documents and Settings\staffuser2.DOMxx1' cfl = '/adm/sa/cfglog' MANPATH = ':/usr/ssl/man' APPDATA = 'C:\Documents and Settings\staffuser2.DOMxx1\Application Data' hostname = 'OurServer108' D = '/drv' LCL_PATH_ADM = 'i:/tcm' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 2 Stepping 7, GenuineIntel' DIRCMD = '/A' WINDIR = 'C:\WINNT' TMPDIR = '/drv/c/TEMP' cu = '/adm/bin/cust' OLDPWD = '/user/staffuser2' USERDOMAIN = 'DOMxx1' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' dc = '/adm/doc' BMC_GLOBALC_HOME = 'c:\Program Files\BMC Software\common\globalc' XCM_MKEP01_DB = '\\OurServer108\bcmdb\xyzp01test' svars_bash_defined = 'yes' PATH_ADM = 'i:/tcm' OVDATADIR = 'C:\HPOV\data\' OS2LIBPATH = 'C:\WINNT\system32\os2\dll;' BASH_BIN = 'c:\aut\cyg\bin' http_proxy = 'http://proxy.OurBiz.com:8080' rg = 'C:\WINNT\system32\config' OVPERLLIB = 'C:\HPOV\nonOv\Perl\a\lib' TEMP = '/drv/c/TEMP/1' RTSERVERS = 'tcp:localhost:2059' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' PATH_ORIG = 'C:\Program Files\EMC\PowerPath\;c:\bcm63\bin;c:\bcm63\jre\bin;c:\cc m63\bin\util;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;c:\aut\perl5\bin; C:\Program Files\Resource Kit\;C:\Program Files\Support Tools\;c:\PROGRA~1\BMCSO F~1\common\globalc\bin\Windows-x86;c:\Progra~1\tivoli\tsm\baclient;c:\PROGRA~1\B MCSOF~1\PATROL~1\bin;C:\Program Files\Symantec\pcAnywhere\;C:\HPOV\bin;C:\HPOV\b in\OpC;' T = '/adm/sa/tmp' DSM_DIR = 'c:\progra~1\tivoli\tsm\baclient' bas = '/adm/bin/app/s' USERNAME = 'staffuser2' PATROL_HOME = 'C:\PROGRA~1\BMCSOF~1\PATROL~1\' doc = '/adm/doc' dv = 'C:\WINNT\system32\drivers' CMUTIL_PATH = 'c:\bcm_util' PROCESSOR_LEVEL = '15' XCM_FILE_SERVER_HOST = 'OurServer108' XCM_PRODUCTION_DB = '\\OurServer108\bcmdb\prodtest' recovery = '/adm/backup/recovery' nu = '/adm/doc/bcm/newuser' PATROL_TEMP = 'C:\PROGRA~1\BMCSOF~1\PATROL~1\tmp' XCM_ENGINE_HOST = 'OurServer108' fdb = '/adm/db/sys/fdb_' c9 = '//OurServer109/c_drive' c8 = '//OurServer108/c_drive' SYSTEMDRIVE = 'C:' b = '/adm/bin/sys' be = '//OurServer109/d_drive/In
Re: ls displays nothing - 3/29 snapshot
On Sun, Apr 02, 2006 at 09:07:28PM -0500, Tom Rodman wrote: >On Sun 4/2/06 15:59 CDT cygwin@cygwin.com wrote: >>On Sun 4/2/06 16:43 EDT cygwin@cygwin.com wrote: >>>On Sun, Apr 02, 2006 at 02:37:22PM -0500, Tom Rodman wrote: I installed the 3/29 cygwin1.dll snapshot yesterday on a test windows 2000 box. Many (all?) of our cron jobs ran normally Sunday morning. Today, though, the output of 'ls' or 'ls -l' from an interactive bash session was always nothing. I've reverted back to the released cygwin1.dll, and ls is working again. Sorry for lack of details; not sure at what point the problem started showing up. >>> >>>That's ok. Minus any details, we'll just assume that you've done >>>something wrong and ignore the problem. >> >>I have a scroll log of all the shell commands I did on Sat/Sun, and >>logs from the cron jobs. Will post if I find anything helpful - so far >>nothing out of the ordinary shows up in STDERR; I'll go over the logs >>again .. > >The problem happens immediately for me with the 3/29 snapshot: What does "happens immediately" mean? It didn't happen with the 2006-03-26 snapshot? It happens more quickly than you'd expect? Did you reboot after installing the snapshot? If rebooting doesn't fix the problem then please send strace output from the following command to the list. c:\>strace -o/tmp/strace.out /bin/bash exec /bin/ls -l /etc/passwd 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: Initialisation with data from dll-libraries
Jørgen Steensgaard-Madsen wrote: Larry Hall (Cygwin cygwin.com> writes: Jørgen Steensgaard-Madsen wrote: Asking for help. You haven't said where the dispatch table is or how it is supposed to filled in. First of all, thanks for reacting so promptly. The dispatch table is an array of pointers in a C-program file to be linked against the libraries. Initialised is expressed as a usual array declaration initialised with individual entries given as &some_function where some_function is declared as extern in the same file. This methods works nicely with static linkage, and also with dynamic linkage on a Linux box. Windows DLLs don't work the same as shared objects. If you want to call functions in a particular DLL, you can link your program against an import library for the DLL which contains the functions you'll be using. The import library provides the stubs for the functions that allow your program to link. At run-time, they ferry your calls across to the DLL implementation. If you don't want this, you can use dlopen and dlsym to programmatically load the DLL with the functions you want to call and get the function pointers. You may be able to adapt the former approach to your existing code with few changes. If that sounds preferable to you, I suggest you read up on Windows DLLs, importing/exporting functions, and import libraries. If you'd prefer the latter route, which is completely portable to Unix/Linux once you've made the initial code changes, I'd recommend reading up on dlopen and dlsym. In either case, neither of these subjects is Cygwin-specific so further discussion of these general areas are really off-topic for this list. -- 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: Spawnvp on pwd.exe and mkdir.exe fails
Brian Kramer wrote:
I have a simple C++ file I am using to spawn pwd.exe and mkdir.exe. These are
causing stackdumps. Can anyone help me resolve this? ls.exe does not cause a
stackdump.
The same C++ file compiles using Visual Studio and the output is as expected.
In particular on Windows:
pid=1996
/cygdrive/e/tempprojects/pwd/Debug
done
And under cygwin:
pid=5860
(pwd.exe.stackdump written)
done
Here's my program:
#include
#include
int main()
{
char* argv[] = {"pwd.exe", 0};
int pid = spawnvp( _P_NOWAIT, argv[0], argv );
printf("pid=%d\n",pid);
int termstat;
cwait( &termstat, pid, WAIT_CHILD );
printf("done\n");
return 0;
}
You should include the path to "pwd.exe" (i.e. "/bin/pwd.exe"). If this
doesn't solve your problem, I suggest you read and follow the problem
reporting guidelines found here:
Problem reports: http://cygwin.com/problems.html
FWIW, with the correction I suggested, this works fine for me with Cygwin
1.5.19.
--
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: Spawnvp on pwd.exe and mkdir.exe fails
Larry Hall (Cygwin cygwin.com> writes:
>
> Brian Kramer wrote:
> > I have a simple C++ file I am using to spawn pwd.exe and mkdir.exe. These
are
> > causing stackdumps. Can anyone help me resolve this? ls.exe does not
cause a
> > stackdump.
> >
> > The same C++ file compiles using Visual Studio and the output is as
expected.
> >
> > In particular on Windows:
> > pid=1996
> > /cygdrive/e/tempprojects/pwd/Debug
> > done
> >
> > And under cygwin:
> > pid=5860
> > (pwd.exe.stackdump written)
> > done
> >
> > Here's my program:
> >
> > #include
> > #include
> >
> > int main()
> > {
> > char* argv[] = {"pwd.exe", 0};
> > int pid = spawnvp( _P_NOWAIT, argv[0], argv );
> > printf("pid=%d\n",pid);
> >
> > int termstat;
> > cwait( &termstat, pid, WAIT_CHILD );
> > printf("done\n");
> >
> > return 0;
> > }
>
> You should include the path to "pwd.exe" (i.e. "/bin/pwd.exe"). If this
> doesn't solve your problem, I suggest you read and follow the problem
> reporting guidelines found here:
>
> > Problem reports: http://cygwin.com/problems.html
>
> FWIW, with the correction I suggested, this works fine for me with Cygwin
> 1.5.19.
>
Hi, Larry. Thanks for your prompt Sunday night reply!
I tried that also. Note that "ls.exe" gives the correct result:
pid=1312
E:\tempprojects\pwd\*.*
[Debug] pwd.suo*
a.exepwd.vcproj
pwd.cpp pwd.vcproj.BKRAMERHOME.bkramer.user
pwd.exe.stackdumpReadMe.txt
pwd.ncb stdafx.cpp
pwd.sln stdafx.h
434176 (400541) bytes in 11 files
done
I normally have c:\cygwin\bin on the path, which is why using "/bin/ls.exe"
and "ls.exe" both work.
I upgraded to Cygwin 1.5.19 today to see if that helped on my real cases
("pwd.exe" and "mkdir.exe"), and it did not. The interesting this is that
this code used to work just fine: something "happened" and I would't know how
to start diagnosing this issue...
Did you run the example I gave?
A clean reinstall of Cygwin, perhaps?
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: Re: 1.5.18-1: syslogd and cron message issue (XP/2000).
Hi Rene, Thanks for taking the time to look at this. In the end I have switched to using syslog-ng. That seems to quite nicely address the issue... And provide a whole other bunch of functionality on top. Still, be interested in hearing anything relevant to this that anyone might come up with! Thanks again and best regards, Doug Irwin > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of René Berber > Sent: Sunday, 2 April 2006 14:37 PM > To: cygwin@cygwin.com > Subject: Re: 1.5.18-1: syslogd and cron message issue (XP/2000). > > René Berber wrote: > [snip] > > After compiling and installing the changed version I'm > getting this ugly message: > > > > Apr 1 18:33:31 b kernel: cron[2812]: segfault at 004060C2 > rip 00402986 rsp > > 0022E850 error 6 > > > > But cron is working normally, so it may be just a non > related problem (possibly > > due to using a Cygwin snapshot because I've seen a couple > of these before). > > Take that back, cron is not working. > -- > René Berber -- 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: Spawnvp on pwd.exe and mkdir.exe fails
Larry, after deleting my cygwin directory and reinstalling, I am able to execute the sample program below correctly. Thanks for your time spent on this! For me... onward! 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/
