NetBurner Community Forum

I hit this error when trying to build the system libraries for the 2.5.0 release. Same thing happens with the command line build. Has anyone else run into this issue?

>>> make clean
AllocationBase 0x0, BaseAddress 0x71110000, RegionSize 0x150000, State 0x10000
>>> make clean libs
>>> make clean libs
0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
>>> make system
0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x71110000, RegionSize 0x150000, State 0x10000
C:\nburn\gcc-m68k\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0
0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
make: *** [ucosmcfc.o] Error 1

Hi Tom: I've rebuilt the SBL2e and 5234 libs successfully from within Eclipse using "rebuild all."

Bah, the old dll rebase problem.

I ran the following in cygwin, and it fixed the issue.
$ rebase -b 0x30000000 msys-1.0.dll

Apparently the windows loader had issues trying to load it at wherever it was based before. This was weird, though, since I had a working 2.4 install with no issues. However, once I installed 2.5, going back to 2.4 didn't resolve the issue.

I wonder if you have a path issue with make, and the wrong make is being called. The tools don't use cygwin, they are mingw. So maybe you have a cygwin installation earlier in your path and its getting called before the mingw make. There is an easy way to test this. Open a command prompt, set your path to: "SET PATH=C:\", run \nburn\setenv.bat (which sets the proper path for that particular command prompt session), then go to \nburn\system and run make clean. If that works you then need to figure out how to set your windows path env. var permanently. I think this can be done through the control panel.

rnixon,

That's what I thought at first as well, so I just moved my cygwin install to a different location. I still had the same issue after the move, so I don't think it was a path issue. I verified that the nburn stuff was first in the path as well. It could be that the cygwin .dll was still loaded, or something weird, even after the move, but I couldn't figure it out.