[devkit] error compiling native extensions

[Erwann]

Hello,

I get an error when I try to install rdiscount as suggested in the
wiki, here is the mkmf.log:

http://pastie.org/1112754

I'm running Win 7 64bits - Ruby 1.9.2 and DevKit-4.5.0-20100819-1536-
sfx.exe installed under C:\ruby\devkit


Any idea?

Thanks
Erwann

[Luis Lavena]

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

[Luis Lavena]

On Tue, Aug 24, 2010 at 2:08 PM, Luis Lavena <luisl...@gmail.com> wrote:
> On Tue, Aug 24, 2010 at 2:05 PM, Erwann <erwa...@gmail.com> wrote:
>> Hello,
>>
>> I get an error when I try to install rdiscount as suggested in the
>> wiki, here is the mkmf.log:
>>
>> http://pastie.org/1112754
>>

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

[Erwann]

> Why inside C:\ruby? Did you write over previous devkit?
>

Why not ? :) If it's not recommended, I can move it to C:
I removed the previous ruby 1.8.7 and devkit files before so the
install is clean with
c:\ruby\devkit
c:\ruby\Ruby192

> 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 ***
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
--without-make-prog
--srcdir=.
--curdir
--ruby=C:/ruby/Ruby192/bin/ruby

[Luis Lavena]

On Tue, Aug 24, 2010 at 2:16 PM, Erwann <erwa...@gmail.com> wrote:
>
>> Why inside C:\ruby? Did you write over previous devkit?
>>
>
> Why not ? :) If it's not recommended, I can move it to C:

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.

[Erwann]

> Well, isn't C:\Ruby\Ruby192 too redundant?

I did it to add C:\Ruby\ruby1.8.7 later and use Pik to choose the
version depending on the projet I'm working on. That's what the Pik's
wiki does so I thought it was the recommended way.

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

What do you mean?

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

There's 3 gems in the cache dir:
columnize-0.3.1
linecache-0.43
rdiscount-1.6.5

I'm going to do a clean install to check if it's ok.

[Luis Lavena]

On Tue, Aug 24, 2010 at 3:07 PM, Erwann <erwa...@gmail.com> wrote:
>
>> Well, isn't C:\Ruby\Ruby192 too redundant?
>
> I did it to add C:\Ruby\ruby1.8.7 later and use Pik to choose the
> version depending on the projet I'm working on. That's what the Pik's
> wiki does so I thought it was the recommended way.
>
>> 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.
>
> What do you mean?
>

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.

[Erwann]

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

Ok, I removed everything and installed as you suggested ruby192 and
Devkit under C:

PS C:\devkit> ruby dk.rb install
[INFO] Installing C:/Ruby192/lib/ruby/1.9.1/rubygems/defaults/
operating_system.rb
[INFO] Installing C:/Ruby192/lib/ruby/site_ruby/devkit.rb

then, when I try to install rdiscount, I get an error again

PS C:\devkit> gem install rdiscount --platform=ruby

Temporarily enhancing PATH to include DevKit...

Building native extensions. This could take a while...

C:\devkit\bin\make.exe: *** Couldn't reserve space for cygwin's heap,
Win32 error 0
ERROR: Error installing rdiscount:
ERROR: Failed to build gem native extension.

C:/Ruby192/bin/ruby.exe extconf.rb
checking for random()... no
checking for srandom()... no
checking for rand()... yes
checking for srand()... yes
creating Makefile

make
0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32
error 487
AllocationBase 0x1140000, BaseAddress 0x1660000, RegionSize 0x6E0000,
State 0x2000
C:\devkit\bin\make.exe: *** Couldn't reserve space for cygwin's heap,
Win32 error 0


Gem files will remain installed in C:/Ruby192/lib/ruby/gems/1.9.1/gems/
rdiscount-1.6.5 for inspection.
Results logged to C:/Ruby192/lib/ruby/gems/1.9.1/gems/rdiscount-1.6.5/
ext/gem_make.out
PS C:\devkit>

and here is the gem_make.out

C:/Ruby192/bin/ruby.exe extconf.rb
checking for random()... no
checking for srandom()... no
checking for rand()... yes
checking for srand()... yes
creating Makefile

make
0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32
error 487
AllocationBase 0x1140000, BaseAddress 0x1660000, RegionSize 0x6E0000,
State 0x2000
C:\devkit\bin\make.exe: *** Couldn't reserve space for cygwin's heap,
Win32 error 0

The mkmf.log file : http://pastie.org/1112957

It's a clean install, I checked the registry, the env path, I don't
understand what's wrong with my setup as it used to work with 1.8.7
and previous devkit

[Jon]

> Ok, I removed everything and installed as you suggested ruby192 and
> Devkit under C:
>
> PS C:\devkit> ruby dk.rb install
> [INFO] Installing C:/Ruby192/lib/ruby/1.9.1/rubygems/defaults/
> operating_system.rb
> [INFO] Installing C:/Ruby192/lib/ruby/site_ruby/devkit.rb
>
> then, when I try to install rdiscount, I get an error again
>
> PS C:\devkit> gem install rdiscount --platform=ruby
> Temporarily enhancing PATH to include DevKit...
> Building native extensions. This could take a while...
> C:\devkit\bin\make.exe: *** Couldn't reserve space for cygwin's heap,
> Win32 error 0
> ERROR: Error installing rdiscount:
> ERROR: Failed to build gem native extension.

What's on your PATH? I see cygwin and suspect it's the source of conflicts...

[Erwann]

> What's on your PATH?  I see cygwin and suspect it's the source of conflicts...

C:\Ruby192\bin for my user and
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;
%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program Files
(x86)\Git\cmd;C:\Program Files\MySQL\MySQL Server 5.1\bin;C:\php

maybe msysgit is using cygwin?

[Jon]

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

[Luis Lavena]

On Tue, Aug 24, 2010 at 3:36 PM, Erwann <erwa...@gmail.com> wrote:
>
> then, when I try to install rdiscount, I get an error again
>
> PS C:\devkit> gem install rdiscount --platform=ruby
> Temporarily enhancing PATH to include DevKit...
> Building native extensions.  This could take a while...
> C:\devkit\bin\make.exe: *** Couldn't reserve space for cygwin's heap,
> Win32 error 0
> ERROR:  Error installing rdiscount:
> ERROR: Failed to build gem native extension.
>
> C:/Ruby192/bin/ruby.exe extconf.rb
> checking for random()... no
> checking for srandom()... no
> checking for rand()... yes
> checking for srand()... yes
> creating Makefile
>

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.

[Erwann]

> 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

I get the same error (I'm using win 7 Home 64bits, not Vista)

c:\Ruby192\bin>gem install rdiscount --platform=ruby

Temporarily enhancing PATH to include DevKit...
Building native extensions. This could take a while...
C:\devkit\bin\make.exe: *** Couldn't reserve space for cygwin's heap,
Win32 erro
r 0
ERROR: Error installing rdiscount:
ERROR: Failed to build gem native extension.

c:/Ruby192/bin/ruby.exe extconf.rb

checking for random()... no
checking for srandom()... no
checking for rand()... yes
checking for srand()... yes
creating Makefile

make
0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32
error 487

AllocationBase 0x1140000, BaseAddress 0x15E0000, RegionSize 0x760000,
State 0x20
00

[Jon]

> > 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
>
> I get the same error (I'm using win 7 Home 64bits, not Vista)

And I was able to install/uninstall rdiscount via PowerShell from my Win7 Ultimate 32-bit with no problems.

[Luis Lavena]

On Tue, Aug 24, 2010 at 4:42 PM, Erwann <erwa...@gmail.com> wrote:
>> 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
>
> I get the same error (I'm using win 7 Home 64bits, not Vista)
>

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

[Luis Lavena]

On Tue, Aug 24, 2010 at 4:48 PM, Luis Lavena <luisl...@gmail.com> wrote:
> On Tue, Aug 24, 2010 at 4:42 PM, Erwann <erwa...@gmail.com> wrote:
>>> 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
>>
>> I get the same error (I'm using win 7 Home 64bits, not Vista)
>>
>
> 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

[Jon]

> >>> 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
> >>
> >> I get the same error (I'm using win 7 Home 64bits, not Vista)
> >>
> >
> > 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?

[Luis Lavena]

msysGit has the dll issue solved since it uses a different base, but
the DevKit depends on MSYS one, not msysGit.

[Jon]

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

[Erwann]

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

I tried to replace the file in git\bin without success. I also
uninstalled git to check and I still get an error

[Luis Lavena]

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

[Erwann]

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

Thanks Luis & Jon, it's ok now :)

I just followed comment #4
rebase -b 0x30000000 msys-1.0.dll

and voila. I don't understand why I didn't encounter the problem with
previous devkit install but at least I know how to solve it now.
Cheers

[Jon]

> > You need to run rebase to change the base address of the DLL (comment #4).
>
> Thanks Luis & Jon, it's ok now :)
>
> I just followed comment #4
> rebase -b 0x30000000 msys-1.0.dll
>
> and voila. I don't understand why I didn't encounter the problem with
> previous devkit install but at least I know how to solve it now.
> Cheers

Great, Luis is spot on again :)

I'm curious as to what else was living at the address on your system
that forced a rebase of DevKit's msys-1.0.dll. If you get a moment,
would you do the following

1) Download http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx
and extract the vmmap.exe somewhere, say C:\winsystools\vmmap

2) Open up a new Command Prompt and type "c:\devkit\msys.bat"

3) Start the vmmap.exe from (1) by double-clicking

4) Select the "sh.exe" process in the vmmap's dialog box and tell me
what lives at the memory address (60800000) shown in this vmmap pic
from my system.

http://img2.mediafire.com/1ed55862d0d249a5f3b5ebb0ba2eac066g.jpg

[Luis Lavena]

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,

[Erwann]

> 3) Start the vmmap.exe from (1) by double-clicking
>
> 4) Select the "sh.exe" process in the vmmap's dialog box and tell me
> what lives at the memory address (60800000) shown in this vmmap pic
> from my system.
>

@Jon
I didn't find any 60800000 as you can see on the screenshot, did I
miss something?
http://www.mediafire.com/imgbnc.php/d77fa643c157efb0c6bc9bf4c2926f4b6g.jpg

@Luis
No, thank *you* for your patience, you did the job!

Cheers,
Erwann

[Jon]

> @Jon
> I didn't find any 60800000 as you can see on the screenshot, did I
> miss something?
> http://www.mediafire.com/imgbnc.php/d77fa643c157efb0c6bc9bf4c2926f4b6g.jpg

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

[Erwann]

> 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

I removed the rebased dll and copied the original msys-1.0.dll, put it
in the exclusion list from Bitdefender and tried to install rdiscount
again but I get the error again

[Jon]

that shoots part of my theory to hell...good thing it was Luis's paycheck ;)

[Luis Lavena]

On Mon, Dec 5, 2011 at 5:38 PM, Jacob W <jwyat...@gmail.com> wrote:
> I am receiving an error very similar to Erwann's. When I tried
> following the steps from comment #4, it is saying 'rebase' is not
> recognized as an internal or external command. What am I doing wrong?
> I downloaded the rebase.exe.

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.