When I issue the "gem update" command on Windows, whenever it gets to a
gem whose latest version DOESN'T have Windows binaries, it'll attempt to
build the native extention which will, of course, fail. For example:
Updating sqlite3-ruby
Building native extensions. This could take a while...
ERROR: While executing gem ... (Gem::Installer::ExtensionBuildError)
ERROR: Failed to build gem native extension.
c:/ruby/bin/ruby.exe extconf.rb update
checking for fdatasync() in rt.lib... no
checking for sqlite3.h... no
nmake
'nmake' is not recognized as an internal or external command,
operable program or batch file.
The old pre-1.x behaviour of asking for the required platform at least
made updating possible. Now I can't update at all unless I uninstall the
troublesome gems (currently sqlite3-ruby and hpricot), run the update,
then re-install the gems using the --version switch.
Does anyone know of a way to get the update command working again on
Windows or am I stuck?
Many thanks,
Charles
on 25.09.2008 10:23
on 25.09.2008 21:28
On Sep 25, 2008, at 01:22 AM, Charles Roper wrote: > > c:/ruby/bin/ruby.exe extconf.rb update > checking for fdatasync() in rt.lib... no > checking for sqlite3.h... no > > nmake > 'nmake' is not recognized as an internal or external command, > operable program or batch file. There is no pre-built sqlite3-ruby for any platform. http://rubyforge.org/frs/?group_id=254&release_id=25302
on 26.09.2008 08:09
Eric Hodel wrote: > On Sep 25, 2008, at 01:22 AM, Charles Roper wrote: >> >> c:/ruby/bin/ruby.exe extconf.rb update >> checking for fdatasync() in rt.lib... no >> checking for sqlite3.h... no >> >> nmake >> 'nmake' is not recognized as an internal or external command, >> operable program or batch file. > > There is no pre-built sqlite3-ruby for any platform. > > http://rubyforge.org/frs/?group_id=254&release_id=25302 Yes, and has been posted about previously (without any replies), not having a pre-built sqlite3-ruby causes "gem update" to fail on Windows systems, preventing other gems to be updated. Is there a way to tell gem update to either skip that one gem , or continue updating the rest of the gems?? Until there's a win32 built version of sqlite3-ruby, this will be causing problems.
on 26.09.2008 08:57
John T. wrote: > Eric Hodel wrote: >> There is no pre-built sqlite3-ruby for any platform. >> >> http://rubyforge.org/frs/?group_id=254&release_id=25302 > > Yes, and has been posted about previously (without any replies), not > having a pre-built sqlite3-ruby causes "gem update" to fail on Windows > systems, preventing other gems to be updated. Yes, this is correct. Previous versions of sqlite3-ruby had win32 versions (e.g. sqlite3-ruby-1.2.3-mswin32.gem) and these installed fine. If I issue the following command, the sqlite3-ruby gem installs just fine: $ gem install sqlite3-ruby --version 1.2.3 Successfully installed sqlite3-ruby-1.2.3-x86-mswin32 1 gem installed Installing ri documentation for sqlite3-ruby-1.2.3-x86-mswin32... Installing RDoc documentation for sqlite3-ruby-1.2.3-x86-mswin32... The problem then comes when I run gem update: gems fails to recognise that the lastest sqlite3-ruby gem does not have a win32 version. It tries to install the latest, incompatible, version, and fails. The whole gem update process then stops, thus making a complete update of all gems impossible. I should also point out that this issue isn't specific to the sqlite3-ruby gem; the hpricot gem also triggers this problem. > Is there a way to tell gem update to either skip that one gem , or > continue updating the rest of the gems?? Until there's a win32 built > version of sqlite3-ruby, this will be causing problems. Yes, I would suggest a few solutions: * Add some logic to gem update that looks for the platform and tests to see if the lastest version of a given gem is compatible with that platform. If it isn't, drop back a version until a compatible version is found. * When a gem fails to update, don't kill the whole update; just skip the gem that wouldn't update. * Allow for an option to be supplied to gem update that skips supplied gems. E.g., gem update --skip sqlite3-ruby hpricot Charles
on 26.09.2008 15:02
Charles Roper wrote: > Yes, I would suggest a few solutions: > > * Add some logic to gem update that looks for the platform and tests to > see if the lastest version of a given gem is compatible with that > platform. If it isn't, drop back a version until a compatible version is > found. > > * When a gem fails to update, don't kill the whole update; just skip the > gem that wouldn't update. > > * Allow for an option to be supplied to gem update that skips supplied > gems. E.g., gem update --skip sqlite3-ruby hpricot > > Charles Amen. I second this! Now, eventmachine is killing gem update. I'm getting a compile error. (Granted this could just be a bug in the eventmachine code, but still...) em.cpp em.cpp(1193) : error C2374: 'i' : redefinition; multiple initialization em.cpp(1186) : see declaration of 'i' NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop.
on 26.09.2008 16:09
John T. wrote: > Now, eventmachine is killing gem update. I'm getting a compile error. > (Granted this could just be a bug in the eventmachine code, but > still...) Same here, although I don't have nmake installed and thus I'm getting the same old failed to build native extension error: $ gem update Updating installed gems Updating eventmachine Building native extensions. This could take a while... ERROR: While executing gem ... (Gem::Installer::ExtensionBuildError) ERROR: Failed to build gem native extension. c:/ruby/bin/ruby.exe extconf.rb update checking for windows.h... no *** extconf.rb failed *** Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers. Check the mkmf.log file for more details. You may need configuration options. Provided configuration options: --with-opt-dir --without-opt-dir --with-opt-include --without-opt-include=${opt-dir}/include --with-opt-lib --without-opt-lib=${opt-dir}/lib --with-make-prog --srcdir=. --curdir --ruby=c:/ruby/bin/ruby Gem files will remain installed in c:/ruby/lib/ruby/gems/1.8/gems/eventmachine-0.12.2 for inspection. Results logged to c:/ruby/lib/ruby/gems/1.8/gems/eventmachine-0.12.2/ext/gem_make.out
on 26.09.2008 16:18
Charles Roper wrote: > John T. wrote: > >> Now, eventmachine is killing gem update. I'm getting a compile error. >> (Granted this could just be a bug in the eventmachine code, but >> still...) > > Same here, although I don't have nmake installed and thus I'm getting > the same old failed to build native extension error: > This machine has installed: Microsoft Visual Studio 6.0 " Visual Studio 2003 " Visual Studio 2005 " Visual Studio 2008 And no combination of command lines will get the gems to compile, so I have no idea how to get it to work. (Any version later than 2003 will bomb with errors about compiler switches that have been deprecated ... if it's not one thing...) Thankfully this is just my work Winders box, and most of my real Rail/Ruby playing is done on OS X :) It just works.
on 26.09.2008 22:23
> Yes, I would suggest a few solutions: > > * Add some logic to gem update that looks for the platform and tests to > see if the lastest version of a given gem is compatible with that > platform. If it isn't, drop back a version until a compatible version is > found. > > * When a gem fails to update, don't kill the whole update; just skip the > gem that wouldn't update. > > * Allow for an option to be supplied to gem update that skips supplied > gems. E.g., gem update --skip sqlite3-ruby hpricot You could also try mingw ruby: http://www.akitaonrails.com/2008/7/26/still-playing-with-ruby-on-windows A little edgey, but hey :) Cheers. -=R
on 27.09.2008 11:12
Roger Pack wrote: > You could also try mingw ruby: > http://www.akitaonrails.com/2008/7/26/still-playing-with-ruby-on-windows > > A little edgey, but hey :) Cool, thanks. I had no idea the new mingw version had come so far. Where's the best place to track progress on it? Do you think now is the time to switch or does it still feel a little *too* edgey? If it's usable, but could do with testing help, I'd be more that happy to help with that effort. As a side note, it's good to see you're using E Text Editor. Awesome editor, eh? Did you see the new snippet pipes feature that was recently rolled in? Here's a post I made about it to the CSS Discuss list with a bunch of screencasts: http://archivist.incutio.com/viewlist/css-discuss/101947 Charles
on 27.09.2008 17:02
> Cool, thanks. I had no idea the new mingw version had come so far. > Where's the best place to track progress on it? > > Do you think now is the time to switch or does it still feel a little > *too* edgey? If it's usable, but could do with testing help, I'd be more > that happy to help with that effort. > As a side note, it's good to see you're using E Text Editor. Awesome > editor, eh? Did you see the new snippet pipes feature that was recently > rolled in? Here's a post I made about it to the CSS Discuss list with a > bunch of screencasts: Well I can't take much credit--I wasn't actually the blog author :) The only concern I have with mingw is that some binary extensions aren't available in a pre-built binary for mingw yet [sqlite, mysql, rmagick] so you have to install them with --platform=mswin32 which is...a little unstable. Other than that I'm sure the OCI guys would love some extra testers and I've used it with success :) You could track progress on the OCI mailing list and/or at http://github.com/luislavena/rubyinstaller/tree/master I believe. Last I heard they were attempting to bundle it with an updated version of OpenSSL or what not. Good luck. -=R
on 27.09.2008 18:30
On Fri, Sep 26, 2008 at 2:09 AM, John T. <johnts@charter.net> wrote: > Is there a way to tell gem update to either skip that one gem , or > continue updating the rest of the gems?? `gem outdated`.split(/\n/).map{|z|z.scan(/^[^[:space:]]+/)}.flatten.map{|z|system("gem update #{z}")} ;-)
on 27.09.2008 18:45
On Sep 27, 7:11 am, Charles Roper <reac...@charlesroper.co.uk> wrote: > *too* edgey? If it's usable, but could do with testing help, I'd be more > that happy to help with that effort. > OCI based on MinGW even is edgy I use on a daily basis, but be warned: You will require install what we call the development kit, which is MinGW (GCC) and, as any *nix OS, you will require the libraries and the headers for the extensions that depend on externals, like SQLite3 or MySQL. Last time I tried to build sqlite3-ruby for MinGW (or even VC6) had a lot of troubles (and didn't find time to play again). MySQL, on the other hand, has binaries, also win32console: gem list --source http://gems.rubyinstaller.org > As a side note, it's good to see you're using E Text Editor. Awesome > editor, eh? Did you see the new snippet pipes feature that was recently > rolled in? Here's a post I made about it to the CSS Discuss list with a > bunch of screencasts: > > http://archivist.incutio.com/viewlist/css-discuss/101947 > I use Intype, E-Text is too much clone of TextMate :-P :-D Regards,
on 27.09.2008 19:37
> OCI based on MinGW even is edgy I use on a daily basis, but be warned: > > You will require install what we call the development kit, which is > MinGW (GCC) and, as any *nix OS, you will require the libraries and > the headers for the extensions that depend on externals, like SQLite3 > or MySQL. > > Last time I tried to build sqlite3-ruby for MinGW (or even VC6) had a > lot of troubles (and didn't find time to play again). > > MySQL, on the other hand, has binaries, also win32console: > > gem list --source http://gems.rubyinstaller.org Wow nice! Rmagick et al. Go OCI team. mingw's looking better every day. Note that sqlite3 appears to have [?] mingw binaries [1] -=R [1] http://weblog.jamisbuck.org/2008/8/27/sqlite3-ruby-1-2-3
on 27.09.2008 23:19
unknown wrote: > `gem > outdated`.split(/\n/).map{|z|z.scan(/^[^[:space:]]+/)}.flatten.map{|z|system("gem > update #{z}")} That didn't quite work, but this did: `gem.bat outdated`.split(/\n/).map{|z|z.scan(/^[^[:space:]]+/)}.flatten.each{|z| `gem.bat update #{z}`} Thanks mysterious unknown person. :) Luis, thank you for the insights, I will give the mingw version a try. > I use Intype, E-Text is too much clone of TextMate :-P You don't like TextMate? That's just crazy talk. :P Seriously though, the Intype developers sure do take a long time to get things done, whereas E Text Editor's author, Alexander Stigsen, is a coding machine. He usually pushes out a release once a week. I do have a look at Intype every so often though. It's not bad. Charles
on 11.12.2008 11:25
Charles Roper wrote: > > That didn't quite work, but this did: > > `gem.bat > outdated`.split(/\n/).map{|z|z.scan(/^[^[:space:]]+/)}.flatten.each{|z| > `gem.bat update #{z}`} > sorry for being so slow... i am new with all these command line how to apply the above code into command line? thank you :)
on 18.12.2008 12:56
Aditya L. wrote: > Charles Roper wrote: >> >> That didn't quite work, but this did: >> >> `gem.bat >> outdated`.split(/\n/).map{|z|z.scan(/^[^[:space:]]+/)}.flatten.each{|z| >> `gem.bat update #{z}`} >> > > sorry for being so slow... i am new with all these command line > how to apply the above code into command line? You need to paste it into a .rb file, then run the .rb file from the command line. I've attached the file I use. Just stick it in C:\ruby\bin (or some other location in your PATH) and then type update_gems from the command line. Hope that helps. Charles
on 18.12.2008 16:12
Hey Many thanks :D will try it now Charles Roper wrote: > Aditya L. wrote: >> Charles Roper wrote: >>> >>> That didn't quite work, but this did: >>> >>> `gem.bat >>> outdated`.split(/\n/).map{|z|z.scan(/^[^[:space:]]+/)}.flatten.each{|z| >>> `gem.bat update #{z}`} >>> >> >> sorry for being so slow... i am new with all these command line >> how to apply the above code into command line? > > You need to paste it into a .rb file, then run the .rb file from the > command line. I've attached the file I use. Just stick it in C:\ruby\bin > (or some other location in your PATH) and then type update_gems from the > command line. > > Hope that helps. > > Charles