Hello,
I am using the RL78 - R5F10TPJ microcontroller on IAR RL78 4.10.1 IDE.My project works fine until I use the default cstartup file in the IAR directory(that is, no adding cstartup file to the project's files).
When I add the cstartup file to the project's files (I copied it from the IAR directory into my project's directory and add it as a file to my project in the IAR), after building the project, I get the duplication definition error as follow:
...
Error[Li006]: duplicate definitions for "@cend"; in ". . . \Code\IAR\3- Workspace\Debug\Obj\cstartup.o", and "cstartup.o(dlrlfnf22n.a)" Error[Li006]: duplicate definitions for "@cstart"; in ". . . \Code\IAR\3- Workspace\Debug\Obj\cstartup.o", and "cstartup.o(dlrlfnf22n.a)" Error[Li006]: duplicate definitions for "__INIT_WRKSEG"; in ". . . \Code\IAR\3- Workspace\Debug\Obj\cstartup.o", and "cstartup.o(dlrlfnf22n.a)" Error[Li006]: duplicate definitions for "__iar_program_start"; in ". . . \Code\IAR\3- Workspace\Debug\Obj\cstartup.o", and "cstartup.o(dlrlfnf22n.a)" Error[Li006]: duplicate definitions for "__program_end"; in ". . . \Code\IAR\3- Workspace\Debug\Obj\cstartup.o", and "cstartup.o(dlrlfnf22n.a)" Error while running Linker
What is the problem?
If I want to add my cstartup file to my project and change it as I want, How can I get rid of these errors?
Thanks
Hi Ebi,
Hope you are well.
I suspect that when you manually include the cstartup file IAR is linking both the file you have included & the default cstartup file.
When using a custom entry point in IAR make sure you override the default program entry point.This can be found: [Right Click Project] --> Options --> Linker --> Library --> Select default program entry.Here define the entry point of your program, this should stop linking in the default cstartup file.
Best regards,
Louis
Hi Louis,
Was there ever any resolution to this issue? I am getting the same linker errors.
We have legacy code previously compiled on IAR v2.21.1 that we are attempting to move to v4.21.1. We were using a modified cstartup.s that we copied into our project directory and it was working fine in v2, but gives linker errors in v4.
Setting a custom entry symbol did not seem to make a difference.
Any thoughts?
Hi mark_nickname,
Have you changed the name of the symbol from the default __iar_program_start?Both in your custom cstart file and in the linker settings.
Best regards,Louis
I suspect that you are right in that IAR is linking my cstartup and the default cstartup. I have tried changing the __iar_program_start name in my cstart and in the linker settings and that change did not help matters.
It is interesting that in IAR v2.21.1 the compile was happy, then I installed v4.21.1 and I get the errors in the v4.21.1 compile and when I go back to the v2.21.1 compile (with v4.21.1 still installed), it now gave me the same errors. Uninstalling the v4.21.1 version now allows the v2.21.1 version to compile without errors again.
I will re-install the v4 version and see what else I can think of early next week.
Thanks,
Mark
The /path/to/v2.21.x/rl78/src/lib/cstartup.s file is not compatible with the /path/to/v4.21.x/rl78/src/lib/cstartup.s. There were significant changes starting from v3.10.1.
Upgrading the compiler/runtime will typically require upgrading the startup code as well. This is done automatically for applications using the stock startup code which is built into the runtime library.
When using custom cstartup.s in the project, one possible approach might be using the initialization supplied with the product as initial reference and then apply the application's required changes on top of it.
The same approach is expected to happen for when the application uses custom IAR ILINK linker configurations (.icf).
Hi Felipe,
Sorry for the long time gap; we were just able to get back to this part of the project.
Your solution fixed our issue. I just had to bring in the v3.10.1 (or in this case v4.21) cstartup.s file, make our modifications in that and add it to our project. Compiled perfectly and it the solution made sense!
Thanks for your feedback, Mark. I'm glad it did work for you.