Compile Error Building System for v2.9.3

[SeeCwriter]

I installed v2.9.3, imported my MOD54415 project, and compiled. It threw numerous linker errors related to cryptolib. So I opened a command prompt at the nburn\system directory and entered "make", and it stops with some compile error. So I used Eclipse to rebuild the system libraries (Rebuild All System Files) and it throws error "Couldn't reserve space for cygwin's heap, Win32 error 0 ..."

v2.9.2 works just fine.

What now?

[Jon]

Hi SeeCwriter,

I'm sorry to hear that you've run into some issues. I'll be happy to help try and work through them.

For the cryptolib issues, when you imported your project, did you create a clean project and import the code, or did you import the entire project from 2.9.2? If you imported the entire project, would you be able to just import the code and see if that helps resolve the issue? If you still get the issue, would you be able to create a new project, and import the code from one of our SSL/TLS examples and see if that builds? The example at nburn\examples\SSL\ssl-web-demo would be a good one.

For the issues building the system files from the command line, can you list the compile errors that you're getting when you type make from the system directory?

Kind Regards,
Jon

[TomNB]

I just ran a test on a clean install and things seem to be fine. The example I tried is ssl-web-demo. Can you do the same as a test case?

[SeeCwriter]

After installing, I created a blank project and then imported the source code. This is how I always move between versions.

I can't test any of the example programs because the most of the system libraries can't be built. I may uninstall v2.9.3 and then reinstall.

The compile error when using make from the commadline is the same "Couldn't reserve space for cygwin's heap, Win32 error 0". And just prior to that error I just noticed this error:

Code: Select all

m68k-elf-ar cr c:\nburn/lib/NetBurner.a httpass.o
   0 [main] us 0 int init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x71110000, RegionSize 0x280000, State 0x10000

[TomNB]

Before reinstalling, one more test. This procedure will only affect the active command prompt session, and will go away once the command prompt is closed.
Open the command prompt
Go to \nburn\system
Type SET PATH=C:\NBURN
Type SET PATH and enter to verify it set correctly
Type setenv to run the setenv.bat file
Now type make and see if it builds
Now chdir to the system directory for your platform and run make there as well

[TomNB]

Those steps are basically to clear your path. Since we don't use cygwin, my guess is you have some other tool or utility based on cygwin and the make utility being called is not the one for our tool set.

[SeeCwriter]

Setting the path in the command prompt then rebuilding the system worked. So I rebuilt the system and the module system files.

When compiling my project I get different errors this time. I'm getting compile errors in system files. For example:

C:\nburn\system/cppmain.cpp:52: undefined reference to 'UserMain(void)'
C:\nburn\system/tcp.cpp:428: undefined reference to 'TcpSendwSum6(...)'

[SeeCwriter]

Looks like I spoke too soon. Looking closer at the output for building the module system files there was an error. I didn't notice it before because the error message was the same color as the normal output, and wasn't the last line of the output.

So I tried rebuilding everything again, beginning with the system files. Did "make clean" then "make". The cygwin error has returned. I never closed the command window so the path should be the same. But just in case I printed it out:
PATH=C:\nburn/gcc-m68k/bin;C:\nburn/pcbin;C:\nburn/gcc-m68k/msys/1.0/bin;C:\nburn

See attached for a screen shot.

SystemBuildOutput.docx

(82.12 KiB) Downloaded 178 times

[TomNB]

Hello,

I don't have an answer for this at the moment, but we are thinking about it. Why you get a cygwin error when the tools don't use cygwin is a bit of a mystery. The only time in the past I have seen that is when a cygwin make.exe was being called instead our our make.exe, but the path experiments we did should have determined that. However, why it worked once for you and not again does not make sense. Just remember that in these experiments what you do in a command prompt only affects that command session; it does not do anything for how eclipse operates, which uses the windows system variables. Is there any way possible that in your testing something your doing is not consistent and that is why it comes and goes?

[TomNB]

Also, if you use git and its extensions, many of those use cygwin.