Guys thanx for keeping the 'printf' thread lively and would especially like to thank Andrew for pointing me out the thing I was overlooking. I'm sort of stuck with another problem. This time its something to with the Error 253. Somehow I was not able to simulate the problem with a dummy program. So really can't pin-point out the problem. The error 253 is popping up with the following arguments: Internal Error(ASMGEN - TRIPLE=02150960) The compiler is dumping it while compiling a line with 'memset' command. I've not failed to include the string.h header file.
Well strange things are happening with me today. I rechecked the data types, memory areas and everything seemed to be fine. I generally recompiled it and guess what ... no no it didn't work out. Still I was having the same damn problem. Before that familiar feeling of throwing the machine out of the window came in I thought of a wise thing and commented out all those statements that were giving me trouble. I then removed the compilation and linker errors of rest of the files and then tried to face the daunting problem again. Guess what this time it worked without cribbing. Only HE knows what happened or probably if you could throw some light on this supernatural phenomenon I would really be glad. Otherwise its OK as my stuff is sort of working. Thanx for listening to me so patiently. Regards, Vipin Mehta
Aha! You must *always* fix the first reported error before worrying too much about following errors. A simple example is if you miss one closing brace: the compiler will then report loads of errors because it will be out of step with *all* the rest of the braces in the rest of your compilation! Then you fix just one mistake and *all* the other error reports disappear! (assuming there were no other mistakes!) If you have many (possibly subtle) errors, the compiler can try to continue but get so confused that it just falls over in a big heap - this is just the sort of time when it will start throwing out its disaster messages like "Internal error xxx..." This applies to *any* compiler. Anyway, glad to hear that it's working now!
Andrew, I'm absolutely aware of the facts that you have put forward and also the example you have mentioned in support of your explanation but if the problem had been of such triviality I would not have even thought of bothering you or anybody on the list. The unfortunate thing was that it was the first error on the "heap" out of several others that appeared. I then commented the problematic stuff and proceeded to correct the rest. Having removed *all* the compilation errors I uncommented the insulting stuff and the internal error beast again made of fun of me. I forgot to tell you that I did all this before removing the linker errors but I am of the strong belief that linking stage comes after the compilation stage. I then proceeded to remove all the linker errors and then finally again tried my luck and it clicked ...
Its just that Philvin is a colleague of mine and we both are working on the same project and use the same machine. Since his was the last mail that was sent by this machine to the list I accidently sent the previous mail without changing the ID fields. Regards, Vipin
Philvin (or is it Vipin?), Sorry if I insulted your experience: sometimes I assume too much, sometimes too little! You're quite right that linking comes after compiling - the linker links what the compiler compiled! What sort of link errors were you getting? Did you fix them by changing the link (options, etc) or by changing source?
I guess the linker errors were of assorted nature. Couple of them because of inappropriate hash definitions. Some others were linked to inconsistent usage of memory areas (I mean variables were defined to reside in some 'x' location but while exporting them to other files I used different memory area 'y'). Regards, Vipin
By "hash definitions" I assume you mean the 'C' preprocessor #define directive? This is a well known source of many "peculiar" errors! To keep your 'extern' declarations & function prototypes in step with the "real" definitions, be sure to put them in header file(s) and #include them where the "real" definitions occur. If they match, everything will be fine; If they don't match, the compiler will give you a "duplicate definition" or "redefinition" or similar warning.
Thanx andrew. I'll take care. Regards, vipin