Why inside C:\ruby? Did you write over previous devkit?
What is failing? mkmf.log is only telling part of the whole thing, we
will need gem_make.out that was generated during gem installation.
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
For the record:
C:\Users\Luis>ruby -v
ruby 1.9.2p0 (2010-08-18) [i386-mingw32]
C:\Users\Luis>gem install rdiscount --platform=ruby
Temporarily enhancing PATH to include DevKit...
Building native extensions. This could take a while...
Successfully installed rdiscount-1.6.5
1 gem installed
Well, isn't C:\Ruby\Ruby192 too redundant?
You're free to choose what you do, but things like that can complicate
others trying to understand your setup for helping you out.
>> What is failing? mkmf.log is only telling part of the whole thing, we
>> will need gem_make.out that was generated during gem installation.
>
> Here is the gem_make.out
>
> C:/ruby/Ruby192/bin/ruby.exe extconf.rb
> Can't handle 1.9.x yet
> *** extconf.rb failed ***
Well, that is clear, do not work for 1.9.x, wonder what version of the
gem is trying to install.
Since you cut the path to the version gem, there is no way for us to know it.
See my other response: it installs, so there is something in your
setup, like a local ".gem" file in the directory you're invoking. A
cached version of the gem, something like that.
The gem you're trying to install (dunno which version) is not prepared
for Ruby 1.9, it clearly tells you that: "Can't handle 1.9.x yet"
That is the extconf.rb output, is not RubyInstaller, RubyGems or Ruby
doing that.
When a gem fails to install its output something like this:
Gem files will remain installed in
C:/Users/Luis/.gem/ruby/x86-mingw32/1.8/gems/mysql2-0.2.3 for
inspection.
Results logged to
C:/Users/Luis/.gem/ruby/x86-mingw32/1.8/gems/mysql2-0.2.3/ext/mysql2/gem_make.out
You didn't paste that when pasted the previous error, so dunno what
version of the gem was the one tried to install.
>
> I'm going to do a clean install to check if it's ok.
>
1.6.5 installed successfully here, so might be something specific to your setup.
Also, when paste the output, please try to include everything. For
example, from your output, I don't know if the DevKit was triggered.
The normal output will display "Temporarily enhancing PATH to include
DevKit..." but since you omitted certain lines, I'm not sure if is
working or not.
What's on your PATH? I see cygwin and suspect it's the source of conflicts...
I have C:\git\cmd on PATH and all works fine for me.
Try creating a "cleanpath.bat" with the following, open up a standard Command Prompt (not PowerShell), run the script, and then try installing rdiscount.
@echo OFF
echo Setting minimal PATH...
set PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem
can you try using a normal command prompt?
Also, I guess you're running Windows Vista?
The make VirtualAlloc is a known issue of msys, which might require a
rebase of msys-1.0.dll under certain systems.
http://old.nabble.com/****-Couldn't-reserve-space-for-cygwin's-heap,-Win32-error-6-td28809741.html
Sorry, I never found the root or the definitive solution for this issue.
And I was able to install/uninstall rdiscount via PowerShell from my Win7 Ultimate 32-bit with no problems.
There is no concrete and solution except for the rebase. You will
require to rebase msys dll
http://comments.gmane.org/gmane.comp.gnu.mingw.msys/4722
Better (concrete instructions) at comment #4 of this msysGit report:
http://code.google.com/p/msysgit/issues/detail?id=180
Interesting...do you know whether the issue goes away with a newer msysGit install?
msysGit has the dll issue solved since it uses a different base, but
the DevKit depends on MSYS one, not msysGit.
I'm just wondering what an easier solution might be.
Since the DevKit has <DEVKIT_ROOT>\mingw\bin\objcopy.exe I wonder if Erwann should try something like this and then try installing the gem...need to specify the XYZ though...
cd <DEVKIT_ROOT>\bin
copy msys-1.0.dll msys-1.0-orig.dll
..\mingw\bin\objcopy --image-base XYZ msys-1.0.dll
No, you should not replace any msysGit file or msys-1.0.dll from DevKit.
You need to run rebase to change the base address of the DLL (comment #4).
Previous devkit was using an old version of msys. The newer version
used a different address and that seems to clash to a small userbase.
It might be a driver, an application like antivirus (low level
integration with kernel) or other thing that is running and
interfering.
We can add to the Troubleshooting page the case and the instructions
as we now know what is the problem.
Erwann, thanks for your patience on not giving up to my sadistic
instructions :-)
Cheers,
Looking at all the DLL's in the general area, I'll bet you Luis's paycheck that it was some transient BitDefender DLL that had stepped in as part of its AV protection scheme.
I'm wondering if setting some sort of exclusion for the msys-1.0.dll in BitDefender would also have fixed the issue.
Jon
that shoots part of my theory to hell...good thing it was Luis's paycheck ;)
Where you downloaded? have you put it somewhere in the PATH that is
accessible by your command prompt?
Remember: download is not enough, is *where* you place that file that
is accessible to the command prompt.
PS: Please reply to the group, so everybody benefits from the responses.