Error while Compiling in Tornado 2.2.1

[vusapkar]

Hello friends,

I am trying to compile my project in Tornado 2.2.1 (vxworks 5.5.1). It
use to compile before but from some days back it has started to give
Error

It says
" f:\Tornado2.2.1\host\x86-win32\lib\gcc-lib\i586-wrs-vxworks\2.9-
PentiumIII-010221\cc1.exe:*** 2. unable to allocate heap,
heap_chunk_size 587202560, Win32 error 8
make: *** [i820Sio.o] Error 0x1 "

Can anyone why this occurs and how to remove it and compile the
project.


Regards,
Vaibhav

[jcas...@gmail.com]

Hi, this may be old, but I just got this error and tried to contact WindRiver. They replied that Tornado 2.2 is at EOL (End of Life) and not supported. Did you ever get a fix to this error?

Thanks

[Muhammad Usman]

[Mark Reap]

Hi,
Not sure if this is any help, but I am trying to fix a very old program without putting a lot of thought/research into it (or learning vxWorks in detail). We ran into the same error getting the same heap_chunk_size of 587202560 which seemed suspicious enough to make me think it was not a memory size on my project settings/target config. Anyway discovered there were two versions of ccppc in my Tornado 2.2 subdirectories and it appeared I was using a \host\x86-wind32\ccppc.exe by default which was a ccppc version 2.7.2. I was able to change the compiler options to use the full path to a different executable, being \host\gnu\3.3\x86-win32\bin\ccppc.exe compiler (instead of the default) which ended up being a ccppc version 3.3. So not sure if the toolchain in the gnu subdir is different or the compiler version difference helped, but since I got past the original error it may provide some insight for someone in the future who actually works with Wind River vxWorks. My wild ass guess is the toolchains are different between the two subdirectories in order to support different hardware targets? Well, I won’t be much help with the details as I am on to many more compiler options for the same project and can’t take the time for more research. Good Luck.

[Joseph Nunley]

I'm not sure if anyone is still looking for a solution, but I was able to resolve the same error by doubling the stack size of ccc1.exe found at the directory that throws the error. I used dumpbin.exe to see the current stack size of ccc1.exe and then editbin.exe double the size. The error arose when upgrading the old Windows XP machine to Windows 10.