What does this warning mean?

Are you translating all your 'C' source files with SRC?

ie, are you translating from 'C' source to Assembler source, and then to object(s)?

It means that for some reasons the startup files and C runtime library weren't pulled into the link of your program. It's a little hard to guess why that would happen, mainly because you didn't supply any of the crucial information. A look at the very first couple of lines of the .map file (which I hope you're having generated), or any other way that gives you the actual linker command line used, would help.

yes, that's true

"It means that for some reasons the startup files and C runtime library weren't pulled into the link of your program."

Yep, that's it

"It's a little hard to guess why that would happen"

Actually, it's not: the reason is that he's converting all his 'C' source into assembler source, then using the assembler to generate the object files. Therefore, all the Linker sees is assembler-generated object files - so it has no reason to include any 'C' runtime!

The answer is either to include the 'C' runtime manually, or just to ensure that there is at least one 'C' source file that is actually translated direct to object by the C51 compiler.

I'm sure there's a knowledgebase article on this.

This does, of course, beg the question of WHY he is converting everything via assembler?!
I always recommend that any bits of the project that need to be written in assembler should be written as proper assembler modules and called from 'C' - rather than messing about with inline assembler.
There's a whole section in the Manual on how to do that.

The problem is that I am using startup.a51 and init.a51, so I think in this case
I should translate all c files to src. If I shouldn't, then how can this be done

Thanks for help

Your question has been answered several times in this thread. Please read the manual on converting 'C' to asm. In your case I think you should leave everythin in 'C' and don't touch startup and init until you can compile and assemble you programs. DO NOT convert your 'C' files to ASM unless you need to do some serious optomizing.Reading this thread I feel the compiler can build much better code than you. Remember the toolset knows the difference between .a* files and c. files. Uv2 will call the correct translator and the linker can care less if the object was created from the compiler or the assemble. Brad

"The problem is that I am using startup.a51 and init.a51"

No, that is not the problem.

"so I think in this case I should translate all c files to src"

No: this is precisely what is causing your problem - as I explained earlier.

You use the SRC directive only if you are using inline assembler - and, as I said before, my opinion is that inline assembler is best avoided.

"DO NOT convert your 'C' files to ASM unless you need to do some serious optomizing." (my emphasis)

Even then, there is no need to convert your 'C' source files to assembler sources files: Just get the compiler to include the generated assembler in its Listing file.

Then, if you do find parts that need hand optimising, write them properly in assembler as assembler modules and call them from 'C' - do NOT mess about with inline assembler!

Well, I guess you are right. When I disabled that choice, it gave no errors.

Thanks. I guess I should take a better look on the user's guide :)

Many thanks again

Then, if you do find parts that need hand optimising, write them properly in assembler as assembler modules and call them from 'C' - do NOT mess about with inline assembler!

How can this be done?

"How can this be done?"

As I said earlier:

There's a whole section in the Manual on how to do that.

Therefore, all the Linker sees is assembler-generated object files - so it has no reason to include any 'C' runtime!

I tend to consider that conclusion to be caused by what IMHO is a defect in the toolchain.

Why should the assembler (and the C compiler in SRC mode) be unable to put the same magic cookie into the .obj file that C51 in normal operation will put in there, to make the linker aware that the C runtime is needed?

I've said this before: if inline assembly is supported, the assembler has to be capaple of to generating exactly the same object files you currently get from directly building object files in the compiler. Including debug info, linker hints, and whatever else there is. I.e.

C51 SRC {options} foo.c
A51 foo.src

C51 {options} foo.c

"I tend to consider that conclusion to be caused by what IMHO is a defect in the toolchain."

The phrase "Not-Entirely-Integrated Development Environment" (NE-IDE) springs to mind, once again... ;-)

Not quite...

First of all, the IDE is quite innocent in this case. It's a problem of the command line tools and how they (fail to) interact.

Second, as I see it it's not really a problem of "not entirely integrated" at all, but rather one of the tools being more integrated than does them any good. There's an object file generator integrated into the compiler, which I'm arguing shouldn't be there. It's duplicate maintenance work for Keil, causes unnecessary confusion on users' side, and reduces versatility of the toolset.

Ceterum Censeo SRC esse fixatum "ON" (and the assembler upgraded accordingly).