Jump to content

I think my compile environment is broke


philetaylor
 Share

Recommended Posts

Hi.

I have been compiling many many midibox apps but something must have happened today (not sure what) as everytime I try to compile any apps (whether my own or ones from ucapps.de) I get the following:

C:\Midibox\dmx_controller>make
rm -rf _output/*
rm -rf _output
rm -rf *.cod *.map *.lst
rm -rf *.hex
mkdir -p _output
sh c:\midibox\mios_base\bin/mios-gpasm -c -p p18f452 -I./src -I c:\midibox\mios_
base/include/asm -I c:\midibox\mios_base/include/share -I c:\midibox\mios_base/m
odules/app_lcd/dummy -I c:\midibox\mios_base/modules/iic_dmx -DDEBUG_MODE=0  -DS
TACK_HEAD=0x37f -DSTACK_IRQ_HEAD=0x33f -I c:\midibox\mios_base/modules/mios_wrap
per c:\midibox\mios_base/modules/mios_wrapper/mios_wrapper.asm  -o _output/mios_
wrapper.o
sh c:\midibox\mios_base\bin/mios-gpasm -c -p p18f452 -I./src -I c:\midibox\mios_
base/include/asm -I c:\midibox\mios_base/include/share -I c:\midibox\mios_base/m
odules/app_lcd/dummy -I c:\midibox\mios_base/modules/iic_dmx -DDEBUG_MODE=0   c:
\midibox\mios_base/modules/app_lcd/dummy/app_lcd.asm -o _output/app_lcd.o
sh c:\midibox\mios_base\bin/mios-sdcc -c -mpic16 -p18f452 --fommit-frame-pointer
 --optimize-goto --optimize-cmp --disable-warning 85 --obanksel=2  -I./src -I c:
\midibox\mios_base/include/c -I c:\midibox\mios_base/include/share -I c:\midibox
\mios_base/modules/iic_dmx -DDEBUG_MODE=0  src/main.c -o _output/main.o
c:/midibox/mios_base/bin/mios-gpasm modifies _output/main.asm, result in _output
/main__mios-gpasm-tmp.asm
      0 [main] sed 3844 open_stackdumpfile: Dumping stack trace to sed.exe.stack
dump
Error [125] Illegal condition (EOF encountered before END)
make: *** [_output/main.o] Error 1

Can anybody shed some light on what I might have done to cause this and more importantly, what I can do to fix it ??? I have lots of disk space and have tried rebooting....

EDIT: sed is version 3.02, make is version 3.81, sdcc is version 2.8.0,  gpasm 0.13.6 beta and gplink is version 0.13.6 alpha...

Cheers

Phil

Link to comment
Share on other sites

Ahh, you too huh.

OK I've been getting those errors - Error 1 and error 5, for some time now. It rarely showed the 'EOF before end' message, but that was the one that helped me to track it down with a file monitor (sysinternals filemon, BTW). That EOF before END is when the OS *thinks* it has opened the file, but can't buffer up the end of it, so it's like it's only opened the first half of your file, to compile it.

They appear at random, and often just typing 'make' again will do the trick. I noticed that it happened more often (sometimes just always) if I launched the cmd.exe instance from late proceses... as in, if I did file...run... cmd.exe, it would be more reliable, than if I opened the prompt from say, notepad++ . A lot of research showed me that windows was failing to open the file for writing - either a disk or ram issue. But of course, any time windows fails to open a file, and lacks a definite reason, it blames RAM or disk by default... Doesn't help much!

I'd tried to lock it down but I knew it was a problem with my machine, and figured it would not effect any one else, so I didn't mention it. Sorry!

Firstly I'd like to ask - how'd you figure out that it was the path being too long?

I decided to check if mine might be over the limits... First I needed to know what the limits are. Here are the goods:

The System path has a maximum length of 1023 bytes, not counting the Path= characters.

The user defined path is the lesser of 511 bytes or (1023 - SystemPath).

By default the maximum PATH environment variable in Windows is 1023. There is a hot fix from Microsoft that increases the maximum length to 2046.

To view the hot fix article, please go to http://support.microsoft.com/kb/832978/en-us

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section. This problem was first corrected in Microsoft Windows XP Service Pack 2.

(so, you don't need the hotfix if you're running SP2 or greater)

http://support.microsoft.com/kb/830473

The box for adding a new user variable is shown below. Generally' date=' this is likely to be a directory that you use frequently but can be any string of less than 8192 bytes. The maximum total size for all environment variables, including variable names and the "equals" sign, is 32767 characters.

[/quote']

Now... this is all legal in my case... for windows at least.... My env vars total is 2247 and path is 617.

But I can't say the same for MinGW. I'm starting to wonder if MinGW supports the same maximums as windows does now.... Maybe it has a 512 char limit on the path....

Let me know how you found this out, maybe I can pin it down and make a bug report...

Link to comment
Share on other sites

They appear at random, and often just typing 'make' again will do the trick. I noticed that it happened more often (sometimes just always) if I launched the cmd.exe instance from late proceses... as in, if I did file...run... cmd.exe, it would be more reliable, than if I opened the prompt from say, notepad++ . A lot of research showed me that windows was failing to open the file for writing - either a disk or ram issue. But of course, any time windows fails to open a file, and lacks a definite reason, it blames RAM or disk by default... Doesn't help much!

At least i'm not alone  :)

I had exactly the same problem, it started over Christmas as random failures when compiling from within notepad++. As I was really 'in the zone' I couldn't be bothered to do any diagnosis at this point as compiling from within a Command Prompt worked fine. I assumed that something had gone screwy and a reboot would fix it (I was wrong!)

I was then forced to do something as yesterday I couldn't even compile from within cmd.exe >:(

I noticed that my path variable was pretty long (definately over 512 bytes) so I decided to 'prune' it as there were lots of things in there that I didn't need (old software etc). Once I had done this everything (including compiling from within Notepad++) worked.

Let me know how you found this out, maybe I can pin it down and make a bug report...

Unfortunately it was trial-and-error and luckilly for me it was the first thing I tried.

I did try running the MinGW "sh" and looking at the environment and it appears to be the same as the windows one, nothing was truncated but as everything else seems to work OK, I would also suspect MinGW.

Cheers

Phil

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...