Try to uninstall the XC8 compiler, clean the folder if something still remain inside (maybe use CCleaner to clean the registry), install again the XC8 compiler v 1.40, then delete the original xclm.exe from the bin folder in the XC8 installation directory and lastly, copy the attached files into the bin folder in the XC8 installation directory.
C preprocessor errors tend to propagate for many lines and finally break the surface nowhere near their original cause. Its probably not seeing the first XCH line, due to a damaged stdio.h or stdlib.h file. Comment out all the except and see what happens. You don't need them except for library functions that explicitly mention them on their page in the manual and should be first anyway.
If you've been careless viewing files in an editor you may have accidentally changed one - look at the modified dates of all the files in and below the XC8 include folder and see if any stand out. If you cant locate the offending file and copy it from another machine with the same XC8 version, you may have to do a reinstall. There may also be undesirable interactions between the Dropbox app and the XC8 compiler. Try creating a new project in a folder that isn't synced by Dropbox. Where did you get the make file from? Go back to the start - keep it as simple as possible so that you can see where the errors are coming from. You should be able to compile 'newmain.c' from the command line.
E.g.: xc8 -chip=16F1459 newmain.c Substitute whatever processor you are using in place of the 16F1459. Bash down Correct all the errors that occur whilst learning how the compiler behaves. Now put what you have learnt into the make file - and onward. I am not sure if this is an error, however, one problem is that your main program is declared as 'void', but you try to return a value. The next problem, hypothetically assuming you get this code through the compiler, is where do you expect this program to 'return' to? I have just tried to compile this.but it certainly can return.
To where is up to the C runtime. In the case of XC8, you will end up with a jump back to 'start' (also generated by the C runtime). Why they don't put a while(1) in the generated code, I don't know. (I didn't make very clear- the newmain.c code shown was generated by MPLABX) When I see generated code for a micro that has 'int main(int argc, char. argv)', I would suspect something is not right.
The 'generator' probably is thinking in 'pc' mode, and not microcontroller mode for some reason. In the case of some early NXP ARMs (LPC2106, LPC2148), there is a one instruction spin loop immediately following the branch and link to main. This is in the file crt.S, the startup file. In this case, it is not provided by any part of the GCC code, it is a separate user generated assembly language file that deals with vectors, startup, and, ultimately, the branch and link to main.
If main happens to return, it will get stuck in the spin loop until the chip is reset. I haven't looked at other processors because I make sure my code won't return. I would suspect most C runtimes for micros simply spin in a loop if returned from main.
Of course, it would be odd to intentionally return from main in a microcontroller. I guess if only using interrupt code one could return from main if you knew that the loop was there (but why). In the case of XC8, I would suspect their reasoning for jumping back to 'start' is to keep the micro running (a software reset would probably be preferred if the reset instruction was available). So, it looks like XC8 considers a return from main as being a mistake, and yet MPLABX generated main code has a return in main. They seem a little conflicted.