Hi all,
Windows 2000
VC++ 6
I recently hit a couple of issues with RC9. First, I
wanted to uninstall and reinstall an old version to
confirm that it was an RC9 issue. But, when I rolled
back to RC7 and tried to build an extension I got
this:
ruby: No such file to load -- ubygems (LoadError)
It turns out that the RUBYOPT environment variable was
causing that. Deleting it solved that problem. So,
may I suggest that the uninstall program remove the
RUBYOPT environment variable as well?
The second issue is with a particular function call
within a C extension. When I tried to build an
extension with the rb_class_new_instance() function, I
would always get this error:
test.rb:12:in `initialize'': Invalid argument
(Errno::EINVAL)
However, when I rolled back to RC7 it worked fine
again. My *guess* is that it''s an issue caused by the
fact that I''m using VC 6 instead of the newer
compiler. But, I wanted to verify that with you all.
If you need some sample code, just check out the
latest CVS code for win32-file in the Win32Utils
project, create a simple text file and try to run this
test script:
require "win32/file"
fh = File.nopen("test.txt")
fh.close
Regards,
Dan
__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
Daniel Berger wrote:> > Hi all, > > Windows 2000 > VC++ 6 > > I recently hit a couple of issues with RC9. First, I > wanted to uninstall and reinstall an old version to > confirm that it was an RC9 issue. But, when I rolled > back to RC7 and tried to build an extension I got > this: > > ruby: No such file to load -- ubygems (LoadError) > > It turns out that the RUBYOPT environment variable was > causing that. Deleting it solved that problem. So, > may I suggest that the uninstall program remove the > RUBYOPT environment variable as well?Oops, that''s my fault. You are correct, I''m not removing the RUBYOPT env var on uninstall.> The second issue is with a particular function call > within a C extension. When I tried to build an > extension with the rb_class_new_instance() function, I > would always get this error: > > test.rb:12:in `initialize'': Invalid argument > (Errno::EINVAL) > > However, when I rolled back to RC7 it worked fine > again. My *guess* is that it''s an issue caused by the > fact that I''m using VC 6 instead of the newer > compiler. But, I wanted to verify that with you all. > > If you need some sample code, just check out the > latest CVS code for win32-file in the Win32Utils > project, create a simple text file and try to run this > test script: > > require "win32/file" > fh = File.nopen("test.txt") > fh.closeI don''t know if this is a vc6 vs. vc7 issue, but I''ll try building your lib and running this test (I may not get to it for a few days I''ve got a very heavy work schedule at the beginning of this week). Thanks for the reports! Curt
Shashank Date wrote:> Daniel Berger wrote: > >> However, when I rolled back to RC7 it worked fine >> again. My *guess* is that it''s an issue caused by the >> fact that I''m using VC 6 instead of the newer >> compiler. But, I wanted to verify that with you all. >> >> > When I tried with VC++ 6 (SP5) I got some other error ("incompatile > binary file format" > or some such). > >> If you need some sample code, just check out the >> latest CVS code for win32-file in the Win32Utils >> project, create a simple text file and try to run this >> test script: >> >> require "win32/file" >> fh = File.nopen("test.txt") >> fh.close >> >> Regards, >> >> Dan >> >> > I had no problem with it (transcript below) after compiling using > VC++ Toolkit 2003. > I am on Win XP Home, using the latest one-click installer (and latest > win32-file from CVS): > > ------------------ > Microsoft Windows XP [Version 5.1.2600] > (C) Copyright 1985-2001 Microsoft Corp. > > C:\win32utils\win32-file>setvc7.cmd > > C:\win32utils\win32-file>set > PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;C:\Program > Files\Microsoft.NET\SDK\v1.1\Bin;C:\Program Files\Microsoft Visual C++ > Toolkit 2003\bin;C:\Program Files\Microsoft SDK\Bin\Win64;C:\Program > Files\Microsoft SDK\Bin;C:\bison\bin;c:\ruby\bin; > > C:\win32utils\win32-file>ruby extconf.rb > checking for GetLongPathName()... yes > creating Makefile > > C:\win32utils\win32-file>nmake clean > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > C:\win32utils\win32-file>nmake > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > cl -nologo -MD -Zi -O2b2xg- -G5 -I. > -Ic:/ruby/lib/ruby/1.8/i386-mswin32 > -Ic:/ruby/lib/ruby/1.8/i386-mswin32 -I. -DHAVE_GETLONGPATHNAME -I. > -I./.. -I./../missing -c -Tcfile.c > file.c > cl -nologo -LD -Fefile.so file.obj msvcrt-ruby18.lib > oldnames.lib user32.lib advapi32.lib wsock32.lib -link > -incremental:no -debug -opt:ref -opt:icf -dll -libpath:"c:/ruby/lib" > -def:file-i386-mswin32.def > Creating library file.lib and object file.exp > > C:\win32utils\win32-file>nmake install > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > install -c -p -m 0755 file.so > c:/ruby/lib/ruby/site_ruby/1.8/i386-msvcrt/win32 > > C:\win32utils\win32-file>type tst_file.rb > require "win32/file" > fh = File.nopen("test.txt") > p fh > fh.close > C:\win32utils\win32-file> > C:\win32utils\win32-file>copy con test.txt > this is a test > ^Z > 1 file(s) copied. > > C:\win32utils\win32-file>ruby tst_file.rb > > C:\win32utils\win32-file>ruby tst_file.rb > #<File:0x2886c28> > > C:\win32utils\win32-file> > ----------------------------------------------------------- > >
Daniel Berger wrote:>However, when I rolled back to RC7 it worked fine >again. My *guess* is that it''s an issue caused by the >fact that I''m using VC 6 instead of the newer >compiler. But, I wanted to verify that with you all. > >When I tried with VC++ 6 (SP5) I got some other error ("incompatile binary file format" or some such).>If you need some sample code, just check out the >latest CVS code for win32-file in the Win32Utils >project, create a simple text file and try to run this >test script: > >require "win32/file" >fh = File.nopen("test.txt") >fh.close > >Regards, > >Dan > >I had no problem with it (transcript below) after compiling using VC++ Toolkit 2003. I am on Win XP Home, using the latest one-click installer (and latest win32-file from CVS): ------------------ Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\win32utils\win32-file>setvc7.cmd C:\win32utils\win32-file>set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;C:\Program Files\Microsoft.NET\SDK\v1.1\Bin;C:\Program Files\Microsoft Visual C++ Toolkit 2003\bin;C:\Program Files\Microsoft SDK\Bin\Win64;C:\Program Files\Microsoft SDK\Bin;C:\bison\bin;c:\ruby\bin; C:\win32utils\win32-file>ruby extconf.rb checking for GetLongPathName()... yes creating Makefile C:\win32utils\win32-file>nmake clean Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. C:\win32utils\win32-file>nmake Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. cl -nologo -MD -Zi -O2b2xg- -G5 -I. -Ic:/ruby/lib/ruby/1.8/i386-mswin32 -Ic:/ruby/lib/ruby/1.8/i386-mswin32 -I. -DHAVE_GETLONGPATHNAME -I. -I./.. -I./../missing -c -Tcfile.c file.c cl -nologo -LD -Fefile.so file.obj msvcrt-ruby18.lib oldnames.lib user32.lib advapi32.lib wsock32.lib -link -incremental:no -debug -opt:ref -opt:icf -dll -libpath:"c:/ruby/lib" -def:file-i386-mswin32.def Creating library file.lib and object file.exp C:\win32utils\win32-file>nmake install Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. install -c -p -m 0755 file.so c:/ruby/lib/ruby/site_ruby/1.8/i386-msvcrt/win32 C:\win32utils\win32-file>type tst_file.rb require "win32/file" fh = File.nopen("test.txt") p fh fh.close C:\win32utils\win32-file> C:\win32utils\win32-file>copy con test.txt this is a test ^Z 1 file(s) copied. C:\win32utils\win32-file>ruby tst_file.rb C:\win32utils\win32-file>ruby tst_file.rb #<File:0x2886c28> C:\win32utils\win32-file> -----------------------------------------------------------
Thanks Shahsank for checking this out. I guess it is a vc6 vs vc7 problem. Curt> -----Original Message----- > From: rubyinstaller-users-bounces@rubyforge.org > [mailto:rubyinstaller-users-bounces@rubyforge.org]On Behalf Of Shashank > Date > Sent: Sunday, November 14, 2004 11:19 PM > To: Daniel Berger; rubyinstaller-users@rubyforge.org > Subject: Re: [Rubyinstaller-users] A couple of issues with RC9 > > > Daniel Berger wrote: > > >However, when I rolled back to RC7 it worked fine > >again. My *guess* is that it''s an issue caused by the > >fact that I''m using VC 6 instead of the newer > >compiler. But, I wanted to verify that with you all. > > > > > When I tried with VC++ 6 (SP5) I got some other error ("incompatile > binary file format" > or some such). > > >If you need some sample code, just check out the > >latest CVS code for win32-file in the Win32Utils > >project, create a simple text file and try to run this > >test script: > > > >require "win32/file" > >fh = File.nopen("test.txt") > >fh.close > > > >Regards, > > > >Dan > > > > > I had no problem with it (transcript below) after compiling using VC++ > Toolkit 2003. > I am on Win XP Home, using the latest one-click installer (and latest > win32-file from CVS): > > ------------------ > Microsoft Windows XP [Version 5.1.2600] > (C) Copyright 1985-2001 Microsoft Corp. > > C:\win32utils\win32-file>setvc7.cmd > > C:\win32utils\win32-file>set > PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WI > NDOWS\Microsoft.NET\Framework\v1.1.4322;C:\Program > > > Files\Microsoft.NET\SDK\v1.1\Bin;C:\Program Files\Microsoft Visual C++ > Toolkit 2003\bin;C:\Program Files\Microsoft SDK\Bin\Win64;C:\Program > Files\Microsoft SDK\Bin;C:\bison\bin;c:\ruby\bin; > > C:\win32utils\win32-file>ruby extconf.rb > checking for GetLongPathName()... yes > creating Makefile > > C:\win32utils\win32-file>nmake clean > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > C:\win32utils\win32-file>nmake > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > cl -nologo -MD -Zi -O2b2xg- -G5 -I. > -Ic:/ruby/lib/ruby/1.8/i386-mswin32 -Ic:/ruby/lib/ruby/1.8/i386-mswin32 > -I. -DHAVE_GETLONGPATHNAME -I. -I./.. -I./../missing -c -Tcfile.c > file.c > cl -nologo -LD -Fefile.so file.obj msvcrt-ruby18.lib > oldnames.lib user32.lib advapi32.lib wsock32.lib -link -incremental:no > -debug -opt:ref -opt:icf -dll -libpath:"c:/ruby/lib" > -def:file-i386-mswin32.def > Creating library file.lib and object file.exp > > C:\win32utils\win32-file>nmake install > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > install -c -p -m 0755 file.so > c:/ruby/lib/ruby/site_ruby/1.8/i386-msvcrt/win32 > > C:\win32utils\win32-file>type tst_file.rb > require "win32/file" > fh = File.nopen("test.txt") > p fh > fh.close > C:\win32utils\win32-file> > C:\win32utils\win32-file>copy con test.txt > this is a test > ^Z > 1 file(s) copied. > > C:\win32utils\win32-file>ruby tst_file.rb > > C:\win32utils\win32-file>ruby tst_file.rb > #<File:0x2886c28> > > C:\win32utils\win32-file> > ----------------------------------------------------------- > > > > > _______________________________________________ > Rubyinstaller-users mailing list > Rubyinstaller-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubyinstaller-users > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.788 / Virus Database: 533 - Release Date: 11/1/2004 >
Curt Hibbs wrote:>Daniel Berger wrote: > > >>But, when I rolled >>back to RC7 and tried to build an extension I got >>this: >> >>ruby: No such file to load -- ubygems (LoadError) >> >>It turns out that the RUBYOPT environment variable was >>causing that. Deleting it solved that problem. So, >>may I suggest that the uninstall program remove the >>RUBYOPT environment variable as well? >> >> >Oops, that''s my fault. You are correct, I''m not removing the RUBYOPT env var on uninstall. > >I have an issue with the setting of RUBYOPT in any case. Unless and until RubyGems is provided by default in Ruby as a whole, this environment variable should not be set on most installs, and the Windows Installer shouldn''t require it in any way whatsoever. (This particularly matters for me as I do NOT want to have RubyGems loaded automatically *ever* with the development that I do.) I don''t mind the inclusion of RubyGems by default, but the enabling of RubyGems in the environment is not a good thing, IMO, because it silently modifies the way that $LOAD_PATH works. Either make this an option (checked by default, for users that don''t care) or provide a couple of scripts to quickly add ubygems to RUBYOPT. When installing, make sure you don''t overwrite an existing RUBYOPT, but append to it. -austin
Austin Ziegler wrote:> > Curt Hibbs wrote: > > >Daniel Berger wrote: > > > > > >>But, when I rolled > >>back to RC7 and tried to build an extension I got > >>this: > >> > >>ruby: No such file to load -- ubygems (LoadError) > >> > >>It turns out that the RUBYOPT environment variable was > >>causing that. Deleting it solved that problem. So, > >>may I suggest that the uninstall program remove the > >>RUBYOPT environment variable as well? > >> > >> > >Oops, that''s my fault. You are correct, I''m not removing the > RUBYOPT env var on uninstall. > > > > > I have an issue with the setting of RUBYOPT in any case. Unless and > until RubyGems is provided by default in Ruby as a whole, this > environment variable should not be set on most installs, and the Windows > Installer shouldn''t require it in any way whatsoever. (This particularly > matters for me as I do NOT want to have RubyGems loaded automatically > *ever* with the development that I do.) > > I don''t mind the inclusion of RubyGems by default, but the enabling of > RubyGems in the environment is not a good thing, IMO, because it > silently modifies the way that $LOAD_PATH works. > > Either make this an option (checked by default, for users that don''t > care) or provide a couple of scripts to quickly add ubygems to RUBYOPT. > When installing, make sure you don''t overwrite an existing RUBYOPT, but > append to it.It should only get set if RubyGems is selected to install (which it is, by default). But having said that I wasn''t thinking along these lines and did not explicitly check that out. I will veryfy and/or fix as appropriate. Thanks, Curt
Austin Ziegler wrote:> > Curt Hibbs wrote: > > >Daniel Berger wrote: > > > > > >>But, when I rolled > >>back to RC7 and tried to build an extension I got > >>this: > >> > >>ruby: No such file to load -- ubygems (LoadError) > >> > >>It turns out that the RUBYOPT environment variable was > >>causing that. Deleting it solved that problem. So, > >>may I suggest that the uninstall program remove the > >>RUBYOPT environment variable as well? > >> > >> > >Oops, that''s my fault. You are correct, I''m not removing the > RUBYOPT env var on uninstall. > > > > > I have an issue with the setting of RUBYOPT in any case. Unless and > until RubyGems is provided by default in Ruby as a whole, this > environment variable should not be set on most installs, and the Windows > Installer shouldn''t require it in any way whatsoever. (This particularly > matters for me as I do NOT want to have RubyGems loaded automatically > *ever* with the development that I do.) > > I don''t mind the inclusion of RubyGems by default, but the enabling of > RubyGems in the environment is not a good thing, IMO, because it > silently modifies the way that $LOAD_PATH works. > > Either make this an option (checked by default, for users that don''t > care) or provide a couple of scripts to quickly add ubygems to RUBYOPT. > When installing, make sure you don''t overwrite an existing RUBYOPT, but > append to it.If RubyGems is installed, then he environment should be enabled. If you don''t want this it would be better to uncheck the rubygems option (and possiby install rubygems yourself later, if that''s what you want). Also, thanks for pointing out the issue of appending to RUBYOPT, not just setting it. RC9 is just setting it, so I need to fix that. Curt
Curt Hibbs wrote:>Austin Ziegler wrote: > > >>Curt Hibbs wrote: >> >> >>>Daniel Berger wrote: >>> >>> >>>>But, when I rolled >>>>back to RC7 and tried to build an extension I got >>>>this: >>>> >>>>ruby: No such file to load -- ubygems (LoadError) >>>> >>>>It turns out that the RUBYOPT environment variable was >>>>causing that. Deleting it solved that problem. So, >>>>may I suggest that the uninstall program remove the >>>>RUBYOPT environment variable as well? >>>> >>>> >>>Oops, that''s my fault. You are correct, I''m not removing the RUBYOPT env var on uninstall. >>> >>> >>I have an issue with the setting of RUBYOPT in any case. Unless and >>until RubyGems is provided by default in Ruby as a whole, this >>environment variable should not be set on most installs, and the Windows >>Installer shouldn''t require it in any way whatsoever. (This particularly >>matters for me as I do NOT want to have RubyGems loaded automatically >>*ever* with the development that I do.) >> >>I don''t mind the inclusion of RubyGems by default, but the enabling of >>RubyGems in the environment is not a good thing, IMO, because it >>silently modifies the way that $LOAD_PATH works. >> >>Either make this an option (checked by default, for users that don''t >>care) or provide a couple of scripts to quickly add ubygems to RUBYOPT. >>When installing, make sure you don''t overwrite an existing RUBYOPT, but >>append to it. >> >> >If RubyGems is installed, then he environment should be enabled. If you >don''t want this it would be better to uncheck the rubygems option (and >possiby install rubygems yourself later, if that''s what you want). > >Also, thanks for pointing out the issue of appending to RUBYOPT, not just >setting it. RC9 is just setting it, so I need to fix that. > > >I don''t agree. This should be a separate option (at best), as RubyGems does not require this option to work. It is recommended, but any application or option provided by the Win32 installer that depends on a library that we are including by RubyGems should be modified before packaging to Do The Right Thing. The same basically applies to RPA if and when we include rpa-base (which, frankly, we should). One of the concerns that I have is precedence. Which has precedence when -rubygems is specified? A library in the system library, the site library, or the Ruby Gem? If it''s the latter, then there is a definite downside to -rubygems. Let me have RubyGems and/or rpa-base installed by default, but don''t change my environment more than you have to. Right now, that should probably extend to PATH and PATH only, because that''s the only change that Ruby (including RubyGems) REQUIRES be done to work properly. Offer to add or change RUBYOPT for users, but don''t make it manditory. -austin