It seems it doesn't matter whether it's a console or a window app, it
fails either way:
rubyw fxri
I've just downloaded one of the mswin32 builds from ruby-lang.org and
it works correctly.
Kent.
···
On 4/30/05, Curt Hibbs <curt@hibbs.com> wrote:
Kent Sibilev wrote:
> I see the same thing on my windows box. It seems that rubyw.exe is
> somehow broken. The same thing happens when you run
>
> rubyw.exe ri
>
> from the bin directory.
I wouldn't expect ri under rubyw.exe, its a console app that expects to
write to stdout.
Curt
Stephan Kämper wrote:
Curt Hibbs wrote:
Endy Tjahjono wrote:
- Created start menu shortcuts for RubyGems gem_server
and viewing the RDoc for installed gems.
The entire ruby shortcuts are created on the installing user start
menu (I installed as Administrator), instead of all users start menu.
And the rights to read, write, etc is set only to the installing user
too. Is this intentional?
Yes, it is.
Curt
I'd be interested in the reason(s) for this.
I'm currently running a programming course at the local community college. Of course the students are not allowed to run whatever they wrote as admins.
Now, not having the start menu available it a bit inconvenient for them.
Would it be possible/acceptable to optionally add the Ruby stuff to all users start menu?
I think its probably reasonable to create the start menu items for "all users". I'll add that to the todo list.
Curt
Curt Hibbs wrote:
VC++ 7.1
Have you confirmed that all extensions are built by VC++ 7.1,
or linked to msvcr71.dll?
All releases of the one-click installer in 2004 and 2005 have been
built with vc++ 7.1, and most included extensions are built from
source.
The few that are now included from binaries (like FXRuby) have have
not been checked. Should they be?
I do see the VC 6.0 RTL and STL are in the distro (msvcrt.dll and msvcp60.dll) so that should be okay if there are VC 6.0 extensions.
I was wondering as I use the Borland compiler for my ruby extensions and since many windows users are probably using your installation, I should probably distribute Borland RTL with my extensions or try to make final with VC7.1.
···
--
J. Lambert
Hi,
At Wed, 27 Apr 2005 12:32:55 +0900,
Curt Hibbs wrote in [ruby-talk:139990]:
> Have you confirmed that all extensions are built by VC++ 7.1,
> or linked to msvcr71.dll?
All releases of the one-click installer in 2004 and 2005 have been built
with vc++ 7.1, and most included extensions are built from source.
The few that are now included from binaries (like FXRuby) have have not
been checked. Should they be?
Yes, definitely. Mixing usage of runtime DLL causes unexpected
results. And recent versions change the ruby DLL name and the
site-wide library directory according to the runtime to get rid
of such hazard.
···
--
Nobu Nakada
Kent Sibilev wrote:
It seems it doesn't matter whether it's a console or a window app, it
fails either way:
rubyw fxri
I've just downloaded one of the mswin32 builds from ruby-lang.org and
it works correctly.
Ok, that a very good indication that the problem is in the build of rubyw.exe (I was thinking it was some weird interaction between my build of rubyw and FXRuby). This should help narrow things down.
Thanks,
Curt
Hmmm.... looks like I need to start building *all* extensions from source to ensure this.
Thanks,
Curt
···
nobu.nokada@softhome.net wrote:
Hi,
At Wed, 27 Apr 2005 12:32:55 +0900,
Curt Hibbs wrote in [ruby-talk:139990]:
Have you confirmed that all extensions are built by VC++ 7.1,
or linked to msvcr71.dll?
All releases of the one-click installer in 2004 and 2005 have been built with vc++ 7.1, and most included extensions are built from source.
The few that are now included from binaries (like FXRuby) have have not been checked. Should they be?
Yes, definitely. Mixing usage of runtime DLL causes unexpected
results. And recent versions change the ruby DLL name and the
site-wide library directory according to the runtime to get rid
of such hazard.
Hi,
At Sat, 30 Apr 2005 15:18:31 +0900,
Curt Hibbs wrote in [ruby-talk:140572]:
> It seems it doesn't matter whether it's a console or a window app, it
> fails either way:
>
> rubyw fxri
>
> I've just downloaded one of the mswin32 builds from ruby-lang.org and
> it works correctly.
Ok, that a very good indication that the problem is in the build of
rubyw.exe (I was thinking it was some weird interaction between my build
of rubyw and FXRuby). This should help narrow things down.
Maybe, msvcrt.dll mismatch between ruby and fox?
···
--
Nobu Nakada
Since your original post on this subject, I've been thinking of this possibility. I'll check it out.
Curt
···
nobu.nokada@softhome.net wrote:
Hi,
At Sat, 30 Apr 2005 15:18:31 +0900,
Curt Hibbs wrote in [ruby-talk:140572]:
It seems it doesn't matter whether it's a console or a window app, it
fails either way:
rubyw fxri
I've just downloaded one of the mswin32 builds from ruby-lang.org and
it works correctly.
Ok, that a very good indication that the problem is in the build of rubyw.exe (I was thinking it was some weird interaction between my build of rubyw and FXRuby). This should help narrow things down.
Maybe, msvcrt.dll mismatch between ruby and fox?
Hi,
At Thu, 28 Apr 2005 01:39:26 +0900,
Lothar Scholz wrote in [ruby-talk:140089]:
> Hmmm.... looks like I need to start building *all* extensions from
> source to ensure this.
Use a tool like the "depends.exe" from older MSVC versions and look
what DLL's are required. You don't need to rebuild all extensions.
$ ruby -e 'Dir["**/*.{dll,so}"].each {|so|
IO.popen("dumpbin -imports #{so}"){|f|
f.grep(/^\s*(ms\w+\.dll)\s*$/i){
dll=$1;puts "#{so}: #{dll}" if /msvcr71/i !~ dll
}
}
}'
bin/libeay32.dll: MSVCRT.dll
bin/libssl32.dll: MSVCRT.dll
bin/msvcp60.dll: MSVCRT.dll
bin/ssleay32.dll: MSVCRT.dll
bin/tcl83.dll: MSVCRT.dll
bin/tclpip83.dll: MSVCRT.dll
bin/tk83.dll: MSVCRT.dll
bin/zlib1.dll: MSVCRT.dll
lib/tcl8.3/dde1.1/tcldde83.dll: MSVCRT.dll
lib/tcl8.3/reg1.0/tclreg83.dll: MSVCRT.dll
freeride/redist/i386-mswin32/ripper.so: MSVCRT.dll
lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox12.so: MSVCRT.dll
lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox12.so: MSVCP60.dll
lib/ruby/site_ruby/1.8/i386-msvcrt/glut.so: MSVCRT.dll
lib/ruby/site_ruby/1.8/i386-msvcrt/opengl.so: MSVCRT.dll
And, why zlib.so is under site_ruby?
···
--
Nobu Nakada
Good question... I'll find out. Thanks for the list.
Curt
···
nobu.nokada@softhome.net wrote:
Hi,
At Thu, 28 Apr 2005 01:39:26 +0900,
Lothar Scholz wrote in [ruby-talk:140089]:
Hmmm.... looks like I need to start building *all* extensions from
source to ensure this.
Use a tool like the "depends.exe" from older MSVC versions and look
what DLL's are required. You don't need to rebuild all extensions.
$ ruby -e 'Dir["**/*.{dll,so}"].each {|so|
IO.popen("dumpbin -imports #{so}"){|f|
f.grep(/^\s*(ms\w+\.dll)\s*$/i){
dll=$1;puts "#{so}: #{dll}" if /msvcr71/i !~ dll
}
}
}'
bin/libeay32.dll: MSVCRT.dll
bin/libssl32.dll: MSVCRT.dll
bin/msvcp60.dll: MSVCRT.dll
bin/ssleay32.dll: MSVCRT.dll
bin/tcl83.dll: MSVCRT.dll
bin/tclpip83.dll: MSVCRT.dll
bin/tk83.dll: MSVCRT.dll
bin/zlib1.dll: MSVCRT.dll
lib/tcl8.3/dde1.1/tcldde83.dll: MSVCRT.dll
lib/tcl8.3/reg1.0/tclreg83.dll: MSVCRT.dll
freeride/redist/i386-mswin32/ripper.so: MSVCRT.dll
lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox12.so: MSVCRT.dll
lib/ruby/gems/1.8/gems/fxruby-1.2.6-mswin32/ext/fox12/fox12.so: MSVCP60.dll
lib/ruby/site_ruby/1.8/i386-msvcrt/glut.so: MSVCRT.dll
lib/ruby/site_ruby/1.8/i386-msvcrt/opengl.so: MSVCRT.dll
And, why zlib.so is under site_ruby?