Link error redefining stdio library functions

Normally, but you would need to make sure you link your file.obj ahead of the runtime library on the command line.

If the runtime lib is first, it'll probably pull in the runtime function then when it hits your file.obj it'll complain about the duplicate.

The build is actually within a CCS project, but it looks like the library comes near the end.
I also tried using preferred order and priority but I still get the error.

"C:\\ti\\ccsv6\\utils\\bin\\gmake" -k all
'Building target: UT_os_core.out'
'Invoking: ARM Linker'
"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.5/bin/armcl" -mv7R4 --code_state=32 --float_support=VFPv3D16
--abi=eabi -me -g --define=TASK_STK_SIZE=512
--define=VSC_UNIT_TEST --define=VSC_INCLUDE_SOURCE_FILE_NAMES --define=VSC_UC_UNIT_TEST
--define=OS_SAFETY_CRITICAL --diag_wrap=off --diag_warning=225 --diag_warning=515
--display_error_number --diag_remark=148 --enum_type=packed -z -m"UT_os_core.map"
--heap_size=0x18000 --stack_size=0x8000 -i"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.5/lib"
-i"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.5/include"
--reread_libs --priority --display_error_number --diag_wrap=off --warn_sections
--xml_link_info="UT_os_core_linkInfo.xml" --rom_model
--preferred_order=OS_COREcti.obj
--preferred_order=OS_COREt.obj
--preferred_order=file.obj
--preferred_order=stubs.obj
-o "UT_os_core.out" "./UnitTest/OS_COREcti.obj" "./UnitTest/OS_COREt.obj" "./UnitTest/file.obj" "./UnitTest/stubs.obj"
"./UnitTest/vsc_iodrv.obj" "./UnitTest/vsc_printf.obj" "./BSP/pinmux.obj" "./BSP/rti.obj" "./BSP/sys_core.obj"
"./BSP/sys_interrupt.obj" "./BSP/sys_intvecs.obj" "./BSP/sys_startup.obj" "./BSP/sys_vim.obj" "./BSP/system.obj"
"../sys_link.cmd"
-l"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.5/lib/rtsv7R4_T_le_v3D16_eabi.lib"
C:/Micrium/uC-OSII/UC038/Source/UnitTest/Cantata/cta.a
C:/Micrium/uC-OSII/UC038/Source/UnitTest/Cantata/cth.a

I don't think that the preferred order option does what you might think (chose between library and source for function). It's got to do with the placement in memory of particular functions.

It looks like you may be into something pretty complex.

The linker might be pulling the file 'fget.c' into the build because it has some other symbol that it needs and that you haven't overridden with your own version. I believe the linker only works at the 'file' level when it includes the runtime support lib. So you can look in the <compiler>\lib\src folder at the file fget.c and maybe see if you've not created everything in that file.

But .. This may be still going into a bit uncharted territory. The compiler manual explains how to add your own IO device driver and it's not done by overriding the runtime library but by adding entries to a device table for the open, close, read, write, lseek, unlink, and rename functions for your particular device.
This would probably be the best way to go if you can ... following the instructions in SPNU151L section 7.2.4.

Otherwise this may be a post that would be better handled by the compiler forum; we can move the post there if you like.

Hi Anthony,

Thanks for the suggestion.  The manual recommended approach may work for us.  In actuality we are  stubbing these the function by setting it to return or return 0, as applicable.  Our test tool uses a combination of mechanisms for result logging.  We and use our own printf for everything.

I don't see anything in the fgetc.c source that should cause this.  It references a couple of extern functions, but no variables.