Here''s the latest output for the record: gcc -I. -I. -Ic:/Ruby18/lib/ruby/1.8/i386-mingw32 -I. -DRUBY_VERSION_CODE=186 -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_SSL_H -g -O2 -c rev_buffer.c rev_buffer.c:630:2: warning: no newline at end of file gcc -I. -I. -Ic:/Ruby18/lib/ruby/1.8/i386-mingw32 -I. -DRUBY_VERSION_CODE=186 -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_SSL_H -g -O2 -c rev_ext.c In file included from rev_ext.c:10: ../libev/ev.c: In function `fd_intern'': ../libev/ev.c:981: warning: passing arg 3 of `rb_w32_ioctlsocket'' from incompatible pointer type In file included from ../libev/ev.c:1191, from rev_ext.c:10: ../libev/ev_select.c: In function `select_poll'': ../libev/ev_select.c:137: error: `NFDBITS'' undeclared (first use in this function) ../libev/ev_select.c:137: error: (Each undeclared identifier is reported only once ../libev/ev_select.c:137: error: for each function it appears in.) make: *** [rev_ext.o] Error 1 -- Thanks! -=R
On Thu, Nov 6, 2008 at 12:24 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:> ../libev/ev_select.c: In function `select_poll'': > ../libev/ev_select.c:137: error: `NFDBITS'' undeclared (first use in > this function) > ../libev/ev_select.c:137: error: (Each undeclared identifier is > reported only once > ../libev/ev_select.c:137: error: for each function it appears in.) > make: *** [rev_ext.o] Error 1 >Can you try the latest version on github? I just upgraded it to libev 3.48, and 3.42 was supposed to fix at least the NFDBITS error -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rev-talk/attachments/20081106/42786eab/attachment.html>
On Thu, Nov 6, 2008 at 2:53 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:> > Can you try the latest version on github? I just upgraded it to libev > 3.48, > > and 3.42 was supposed to fix at least the NFDBITS error > > > > Nice--it does seem to get farther. Here''s the latest: >Okay, that should be fixed now. Try again. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rev-talk/attachments/20081106/f279c1c8/attachment.html>
Roger Pack
2008-Nov-08 07:19 UTC
[Rubyinstaller-devel] Fwd: [Rev-talk] latest on windows mingw...
Anybody run into similar errors to these before? (these while building rev on mingw) gcc -shared -s -o rev_ext.so rev_buffer.o rev_ext.o rev_io_watcher.o rev_loop.o rev_ssl.o rev_timer_watcher.o rev_utils.o rev_watcher.o -L. -Lc:/Ruby18/lib -L. -Wl,--enable-auto-image-base,--enable-auto-import,--export-all -lmsvcrt-ruby18 -lshell32 -lws2_32 -lssl -lcrypto rev_ssl.o: In function `Rev_SSL_IO_ssl_setup'': c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:130: undefined reference to `ossl_ssl_ex_ptr_idx'' c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:132: undefined reference to `ossl_ssl_ex_vcb_idx'' c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:134: undefined reference to `ossl_ssl_ex_client_cert_cb_idx'' c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:136: undefined reference to `ossl_ssl_ex_tmp_dh_callback_idx'' c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:121: undefined reference to `ossl_raise'' collect2: ld returned 1 exit status Also...this is what I currently get with "rake test"... 1607 tests, 15690 assertions, 8 failures, 50 errors I suppose that the glimmer of good news is that mingw passes all the tests for 1.9 :) Thanks for your help. I would fork and do pull requests but have yet to figure out how to get mingw git to use private keys... -=R
Roger Pack
2008-Nov-08 07:45 UTC
[Rubyinstaller-devel] [Rev-talk] latest on windows mingw...
> I would fork and do pull requests but have yet to figure out how to > get mingw git to use private keys...K got a fork to work, but...now the second I check it out and do git status it shows C:\dev\rubyinstaller_my_fork>git status C:\dev\rubyinstaller_my_fork>"c:\Program Files\Git_here"\bin\git status # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: resources/installer/devkit.wxi # modified: resources/installer/mingw.wxs # modified: resources/installer/msys.wxs # modified: resources/installer/msys_stubs.wxs # modified: resources/installer/ruby_bin.wxs # modified: resources/installer/ruby_lib.wxs # modified: resources/installer/rubygems_bin.wxs # modified: resources/installer/rubygems_lib.wxs # modified: resources/msys_stubs/bin/gcc.bat # modified: resources/msys_stubs/bin/make.bat # modified: resources/msys_stubs/bin/sh.bat I think maybe it''s tweaking the line endings on their way in. Will that be a problem? Can I avoid that? Thanks for your help with this. In other news sometimes I have the weird "csrss+irb using 100% cpu even on a computer with no virus scanner--but currently only with 1.8.6 and not with 1.9. Odd. -=R
Luis Lavena
2008-Nov-08 14:43 UTC
[Rubyinstaller-devel] Fwd: [Rev-talk] latest on windows mingw...
On Sat, Nov 8, 2008 at 4:19 AM, Roger Pack <rogerpack2005 at gmail.com> wrote:> Anybody run into similar errors to these before? (these while building > rev on mingw) > > gcc -shared -s -o rev_ext.so rev_buffer.o rev_ext.o rev_io_watcher.o > rev_loop.o rev_ssl.o rev_timer_watcher.o rev_utils.o rev_watcher.o -L. > -Lc:/Ruby18/lib -L. > -Wl,--enable-auto-image-base,--enable-auto-import,--export-all > -lmsvcrt-ruby18 -lshell32 -lws2_32 -lssl -lcrypto > rev_ssl.o: In function `Rev_SSL_IO_ssl_setup'': > c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:130: undefined reference > to `ossl_ssl_ex_ptr_idx'' > c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:132: undefined reference > to `ossl_ssl_ex_vcb_idx'' > c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:134: undefined reference > to `ossl_ssl_ex_client_cert_cb_idx'' > c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:136: undefined reference > to `ossl_ssl_ex_tmp_dh_callback_idx'' > c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:121: undefined reference > to `ossl_raise'' > collect2: ld returned 1 exit status >Maybe the OpenSSL version used by RubyInstaller is not the same one expected by Rev?> Also...this is what I currently get with "rake test"... > > 1607 tests, 15690 assertions, 8 failures, 50 errors >That''s rubyinstaller tests? so we have now 8 failures... was 5 last time.> I suppose that the glimmer of good news is that mingw passes all the > tests for 1.9 :) >Cool!> Thanks for your help. > I would fork and do pull requests but have yet to figure out how to > get mingw git to use private keys... >msysgit + pageant for your keys and ensure GIT_SSH is set and point to the full path of plink.exe (e.g. C:\Program Files\PuTTY\plink.exe) or you can generate a pair of keys with ssh-keygen inside the bash environment of msysGit and use ssh. -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams
Luis Lavena
2008-Nov-08 14:46 UTC
[Rubyinstaller-devel] [Rev-talk] latest on windows mingw...
On Sat, Nov 8, 2008 at 4:45 AM, Roger Pack <rogerpack2005 at gmail.com> wrote:>> I would fork and do pull requests but have yet to figure out how to >> get mingw git to use private keys... > > K got a fork to work, but...now the second I check it out and do git > status it shows > > > C:\dev\rubyinstaller_my_fork>git status > > C:\dev\rubyinstaller_my_fork>"c:\Program Files\Git_here"\bin\git status > # On branch master > # Changed but not updated: > # (use "git add <file>..." to update what will be committed) > # > # modified: resources/installer/devkit.wxi > # modified: resources/installer/mingw.wxs > # modified: resources/installer/msys.wxs > # modified: resources/installer/msys_stubs.wxs > # modified: resources/installer/ruby_bin.wxs > # modified: resources/installer/ruby_lib.wxs > # modified: resources/installer/rubygems_bin.wxs > # modified: resources/installer/rubygems_lib.wxs > # modified: resources/msys_stubs/bin/gcc.bat > # modified: resources/msys_stubs/bin/make.bat > # modified: resources/msys_stubs/bin/sh.bat > > I think maybe it''s tweaking the line endings on their way in. > > Will that be a problem? Can I avoid that? > Thanks for your help with this. >OMG, another victim of autocrlf! please, in your .gitconfig file for your user set: [core] autocrlf = false And do the clone again. the msysGit guys thinks is cool do that magic trick in the background, but is not.> In other news sometimes I have the weird "csrss+irb using 100% cpu > even on a computer with no virus scanner--but currently only with > 1.8.6 and not with 1.9. Odd.That''s odd, never got that, and even I''m suing NOD32. Maybe there are other roots for that issue that we must investigate. I''ll bet is related to readline, but who knows :-P -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams
Roger Pack
2008-Nov-09 04:05 UTC
[Rubyinstaller-devel] [Rev-talk] latest on windows mingw...
> please, in your .gitconfig file for your user set: > > [core] > autocrlf = falseCool thought it might be that. I''ll try that instead :) note that it appears the .gitconfig file for mingw git is c:\documents and and settings\username\.gitconfig # or is it \git\.config and that in order to add to it using "git config" you may need to create the .git file [or some file or other] by hand first. Yipes.> That''s odd, never got that, and even I''m suing NOD32. Maybe there are > other roots for that issue that we must investigate. I''ll bet is > related to readline, but who knows :-PI should look at it sometime. strace only reveals: [T1400] PeekConsoleInputA(f, 2461ec8, 3, 2461f1c, ...) = 1 [T1400] LeaveCriticalSection(77c61a88, 2462038, 77c2eaff, 3, ...) = 0 [T1400] GetCurrentThreadId(2461b40, 246ffe0, 2461f58, 66b97ea9, ...) = 578 [T1400] EnterCriticalSection(77c61a88, 29b20d0, 2462038, 77c2eaf1, ...) = 0 [T1400] GetNumberOfConsoleInputEvents(f, 2461f20, 2bb0720, 29b20d0, ...) = 1 [T1400] PeekConsoleInputA(f, 2461ec8, 3, 2461f1c, ...) = 1 [T1400] LeaveCriticalSection(77c61a88, 2462038, 77c2eaff, 3, ...) = 0 [T1400] GetCurrentThreadId(2461b40, 246ffe0, 2461f58, 66b97ea9, ...) = 578 [T1400] EnterCriticalSection(77c61a88, 29b20d0, 2462038, 77c2eaf1, ...) = 0 [T1400] GetNumberOfConsoleInputEvents(f, 2461f20, 2bb0720, 29b20d0, ...) = 1 [T1400] PeekConsoleInputA(f, 2461ec8, 3, 2461f1c, ...) = 1 repeated and repeated...hmm. ruby-prof might help me here. Thanks for your help. Hopefully sometime I''ll get an up to date version to test :) Any ideas why c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:130: undefined reference> to `ossl_ssl_ex_ptr_idx''might occur in windows not linux? -=R
Roger Pack
2008-Nov-11 07:33 UTC
[Rubyinstaller-devel] Fwd: [Rev-talk] latest on windows mingw...
> That''s rubyinstaller tests? so we have now 8 failures... was 5 last time.Yeah I get 5 now :)>> I suppose that the glimmer of good news is that mingw passes all the >> tests for 1.9 :) >> > > Cool!I have been having fun trying to figure out how to get 1.9 to compile without cygwin help. I think you can hack it to work. [i.e. run make, then when it errs, run make in the extension directories one by one, then make install]. I should look more closely at the 1.8 recipes and see if they''d help me out In other news 1.9 mingw passes ''make test'' [all 918] but errs on some make test-all. Well we do what we can :) Thanks for your help on this. Hopefully it will make a bigger and badder ruby for all of us. I''d be happy to hack on some of the 1.8.7 errors--I just need approval that I''m not breaking something by fixing them :) -=R
More news--that branch now implements the ''libev.o'' file [and ev_wrap.h] and also a hacky hack to get it to work with 1.9. I am still not sure why but this time ruby was defining a function ''ioctlsocket'' within itself [winsock also defines that function in ws2_32] so linking to ruby first then winsock was hurting libev. Go figure. Anyway it works with 1.9 now. Phew :) Note that currently for windows [and probably for linux too] if you pass too many file descriptors or descriptors who are numbered too high, they might not fit within the fd_set and will be silently ignores, so there''s still some lurking scariness in there. I wouldn''t expect it to cause problems for web servers, but if you using it to outgoing connections...it might not work past a certain number. also as a note, ctrl+c doesn''t work with it currently in windows + 1.9 [until you break out of the loop], which is unexpected. Thanks. -=R On Thu, Nov 13, 2008 at 4:01 PM, Tony Arcieri <tony at medioh.com> wrote:> On Thu, Nov 13, 2008 at 2:24 PM, Roger Pack <rogerpack2005 at gmail.com> wrote: >> >> That''s a branch on my fork of the project. I''m not sure exactly how >> to merge it over. >> >> http://bradlyfeeley.com/2008/09/03/update-a-github-fork-from-the-original-repo/ >> might work. > > Yeah I''ve done a pull from someone else''s fork. Cool. If you''re stuff''s > ready to pull I''ll go ahead and do that. > >> >> A couple of refactors might help: including a local "ev_wrap.h" >> instead of ../libev/ev.h" [then you can put windows specific defines >> in it]. Also splitting out the #include<ev.c> part into its own file >> [thus its own .o file] I think might help with the weird macro >> overwritings. Tough to tell. > > Yeah, I can move libev into its own .o file. The preprocessor approach was > just recommended by libev''s author, but now it seems to be causing problems. > > Cool, I''ll do a pull tonight and get it merged into my branch. > > Thanks, and great news on Windows support.
Cool... I tried to do a pull but couldn''t get it to work. Let me try again... On Sat, Nov 15, 2008 at 6:45 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:> More news--that branch now implements the ''libev.o'' file [and > ev_wrap.h] and also a hacky hack to get it to work with 1.9. I am > still not sure why but this time ruby was defining a function > ''ioctlsocket'' within itself [winsock also defines that function in > ws2_32] so linking to ruby first then winsock was hurting libev. > Go figure. > Anyway it works with 1.9 now. Phew :) > > Note that currently for windows [and probably for linux too] if you > pass too many file descriptors or descriptors who are numbered too > high, they might not fit within the fd_set and will be silently > ignores, so there''s still some lurking scariness in there. I wouldn''t > expect it to cause problems for web servers, but if you using it to > outgoing connections...it might not work past a certain number. > > also as a note, ctrl+c doesn''t work with it currently in windows + 1.9 > [until you break out of the loop], which is unexpected. > > Thanks. > -=R > > > On Thu, Nov 13, 2008 at 4:01 PM, Tony Arcieri <tony at medioh.com> wrote: > > On Thu, Nov 13, 2008 at 2:24 PM, Roger Pack <rogerpack2005 at gmail.com> > wrote: > >> > >> That''s a branch on my fork of the project. I''m not sure exactly how > >> to merge it over. > >> > >> > http://bradlyfeeley.com/2008/09/03/update-a-github-fork-from-the-original-repo/ > >> might work. > > > > Yeah I''ve done a pull from someone else''s fork. Cool. If you''re stuff''s > > ready to pull I''ll go ahead and do that. > > > >> > >> A couple of refactors might help: including a local "ev_wrap.h" > >> instead of ../libev/ev.h" [then you can put windows specific defines > >> in it]. Also splitting out the #include<ev.c> part into its own file > >> [thus its own .o file] I think might help with the weird macro > >> overwritings. Tough to tell. > > > > Yeah, I can move libev into its own .o file. The preprocessor approach > was > > just recommended by libev''s author, but now it seems to be causing > problems. > > > > Cool, I''ll do a pull tonight and get it merged into my branch. > > > > Thanks, and great news on Windows support. > _______________________________________________ > Rev-talk mailing list > Rev-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/rev-talk >-- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rev-talk/attachments/20081116/c414d81b/attachment-0001.html>
And there we go... pulled and merged successfully. On Sun, Nov 16, 2008 at 2:28 PM, Tony Arcieri <tony at medioh.com> wrote:> Cool... I tried to do a pull but couldn''t get it to work. Let me try > again... > > > On Sat, Nov 15, 2008 at 6:45 PM, Roger Pack <rogerpack2005 at gmail.com>wrote: > >> More news--that branch now implements the ''libev.o'' file [and >> ev_wrap.h] and also a hacky hack to get it to work with 1.9. I am >> still not sure why but this time ruby was defining a function >> ''ioctlsocket'' within itself [winsock also defines that function in >> ws2_32] so linking to ruby first then winsock was hurting libev. >> Go figure. >> Anyway it works with 1.9 now. Phew :) >> >> Note that currently for windows [and probably for linux too] if you >> pass too many file descriptors or descriptors who are numbered too >> high, they might not fit within the fd_set and will be silently >> ignores, so there''s still some lurking scariness in there. I wouldn''t >> expect it to cause problems for web servers, but if you using it to >> outgoing connections...it might not work past a certain number. >> >> also as a note, ctrl+c doesn''t work with it currently in windows + 1.9 >> [until you break out of the loop], which is unexpected. >> >> Thanks. >> -=R >> >> >> On Thu, Nov 13, 2008 at 4:01 PM, Tony Arcieri <tony at medioh.com> wrote: >> > On Thu, Nov 13, 2008 at 2:24 PM, Roger Pack <rogerpack2005 at gmail.com> >> wrote: >> >> >> >> That''s a branch on my fork of the project. I''m not sure exactly how >> >> to merge it over. >> >> >> >> >> http://bradlyfeeley.com/2008/09/03/update-a-github-fork-from-the-original-repo/ >> >> might work. >> > >> > Yeah I''ve done a pull from someone else''s fork. Cool. If you''re >> stuff''s >> > ready to pull I''ll go ahead and do that. >> > >> >> >> >> A couple of refactors might help: including a local "ev_wrap.h" >> >> instead of ../libev/ev.h" [then you can put windows specific defines >> >> in it]. Also splitting out the #include<ev.c> part into its own file >> >> [thus its own .o file] I think might help with the weird macro >> >> overwritings. Tough to tell. >> > >> > Yeah, I can move libev into its own .o file. The preprocessor approach >> was >> > just recommended by libev''s author, but now it seems to be causing >> problems. >> > >> > Cool, I''ll do a pull tonight and get it merged into my branch. >> > >> > Thanks, and great news on Windows support. >> _______________________________________________ >> Rev-talk mailing list >> Rev-talk at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rev-talk >> > > > > -- > Tony Arcieri > medioh.com >-- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rev-talk/attachments/20081120/ee7ad45c/attachment.html>
And now it won''t compile, whoops... were you wanting me to pull from that other branch? On Thu, Nov 20, 2008 at 11:36 AM, Tony Arcieri <tony at medioh.com> wrote:> And there we go... pulled and merged successfully. > > > On Sun, Nov 16, 2008 at 2:28 PM, Tony Arcieri <tony at medioh.com> wrote: > >> Cool... I tried to do a pull but couldn''t get it to work. Let me try >> again... >> >> >> On Sat, Nov 15, 2008 at 6:45 PM, Roger Pack <rogerpack2005 at gmail.com>wrote: >> >>> More news--that branch now implements the ''libev.o'' file [and >>> ev_wrap.h] and also a hacky hack to get it to work with 1.9. I am >>> still not sure why but this time ruby was defining a function >>> ''ioctlsocket'' within itself [winsock also defines that function in >>> ws2_32] so linking to ruby first then winsock was hurting libev. >>> Go figure. >>> Anyway it works with 1.9 now. Phew :) >>> >>> Note that currently for windows [and probably for linux too] if you >>> pass too many file descriptors or descriptors who are numbered too >>> high, they might not fit within the fd_set and will be silently >>> ignores, so there''s still some lurking scariness in there. I wouldn''t >>> expect it to cause problems for web servers, but if you using it to >>> outgoing connections...it might not work past a certain number. >>> >>> also as a note, ctrl+c doesn''t work with it currently in windows + 1.9 >>> [until you break out of the loop], which is unexpected. >>> >>> Thanks. >>> -=R >>> >>> >>> On Thu, Nov 13, 2008 at 4:01 PM, Tony Arcieri <tony at medioh.com> wrote: >>> > On Thu, Nov 13, 2008 at 2:24 PM, Roger Pack <rogerpack2005 at gmail.com> >>> wrote: >>> >> >>> >> That''s a branch on my fork of the project. I''m not sure exactly how >>> >> to merge it over. >>> >> >>> >> >>> http://bradlyfeeley.com/2008/09/03/update-a-github-fork-from-the-original-repo/ >>> >> might work. >>> > >>> > Yeah I''ve done a pull from someone else''s fork. Cool. If you''re >>> stuff''s >>> > ready to pull I''ll go ahead and do that. >>> > >>> >> >>> >> A couple of refactors might help: including a local "ev_wrap.h" >>> >> instead of ../libev/ev.h" [then you can put windows specific defines >>> >> in it]. Also splitting out the #include<ev.c> part into its own file >>> >> [thus its own .o file] I think might help with the weird macro >>> >> overwritings. Tough to tell. >>> > >>> > Yeah, I can move libev into its own .o file. The preprocessor approach >>> was >>> > just recommended by libev''s author, but now it seems to be causing >>> problems. >>> > >>> > Cool, I''ll do a pull tonight and get it merged into my branch. >>> > >>> > Thanks, and great news on Windows support. >>> _______________________________________________ >>> Rev-talk mailing list >>> Rev-talk at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rev-talk >>> >> >> >> >> -- >> Tony Arcieri >> medioh.com >> > > > > -- > Tony Arcieri > medioh.com >-- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rev-talk/attachments/20081120/3976a93b/attachment.html>