Rubyinstaller devel - Nov 2008 - latest on windows mingw...

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>

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

> 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

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

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

> please, in your .gitconfig file for your user set:
>
> [core]
>  autocrlf = false
Cool 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 :-P
I 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

> 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>