Linker: error #10056: symbol "__TI_int59" redefined

Be sure the linker sees common.lib before it sees the compiler RTS library.  To affect the order in which the linker takes files from libraries, use the option --priority.  If you use the option --reread_libs, remove it.  You can read about those options in the ARM assembly tools manual.

Thanks and regards,

-George

Thanks for the reply.   Linking with --priority and without --reread_libs doesn't change the result.  The console output lists the "-l" for common.lib before any others, so it should be read first, I think.  "-llibc.a" is the reference to the runtime, is it not?

--------------------------

'Invoking: MSP430 Linker'

"c:/ti/ccsv6/tools/compiler/msp430_4.3.3/bin/cl430" -vmspx --abi=eabi --data_model=restricted -O2 -g --define=ISR_TIMING_SIGNALS --define=__MSP430F67691__ --diag_warning=225 --display_error_number --diag_wrap=off --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --single_inline --remove_hooks_when_inlining --printf_support=full --check_misra="required" -z -m"mdu.map" --heap_size=1000 --stack_size=3000 --use_hw_mpy=F5 --cinit_hold_wdt=on -i"C:/.../common/Debug" -i"C:/.../emeter-toolkit/Debug" -i"c:/ti/ccsv6/ccs_base/msp430/include" -i"c:/ti/ccsv6/tools/compiler/msp430_4.3.3/include" -i"c:/ti/ccsv6/ccs_base/msp430/lib/5xx_6xx_FRxx" -i"c:/ti/ccsv6/tools/compiler/msp430_4.3.3/lib" --priority --warn_sections --display_error_number --diag_wrap=off --xml_link_info="mdu_linkInfo.xml" --rom_model -o "mdu.out"  "./src/calibration.obj" "./src/functional_test.obj" "./src/main.obj" "./src/mdu-background.obj" "./src/mdu-foreground.obj" "./src/mdu_console.obj" "./src/mdu_shell.obj" "./src/opto-port.obj" "../lnk_msp430f67691.cmd" -l"C:\..\common.lib" -l"C:\...\IEC60730.lib" -l"libmath.a" -l"libc.a" -l"C:\...\ssm.lib"

<Linking>

error #10056: symbol "__TI_int59" redefined: first defined in "c:/ti/ccsv6/tools/compiler/msp430_4.3.3/lib/rts430x_lc_rd_eabi.lib<int59.obj>"; redefined in "C:\...\common.lib<serial.obj>"

------------------------------------

I've selected <automatic> for runtime support library in the CCS General properties page.

Yes, libc.a is the shorthand for the compiler's RTS library.

Perhaps one or the other libraries defines __TI_int59 in the same section as a different symbol that you really do need, and __TI_int59 gets dragged along for the ride.  This isn't supposed to be the case, but it's possible.  Where does common.lib come from?  Does it define any other interrupt handler functions?

Great suggestion. I have other ISRs in another file.  It is referenced in the linker command as an ".obj" file, which is listed before common.lib.  This is probably the cause of the problem.  How do I fix it?

"c:/ti/ccsv6/tools/compiler/msp430_4.3.3/bin/cl430" -vmspx --abi=eabi --data_model=restricted -O2 -g --define=ISR_TIMING_SIGNALS --define=__MSP430F67691__ --diag_warning=225 --display_error_number --diag_wrap=off --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --single_inline --remove_hooks_when_inlining --printf_support=full --check_misra="required" -z -m"mdu.map" --heap_size=1000 --stack_size=3000 --use_hw_mpy=F5 --cinit_hold_wdt=on -i"C:/.../common/Debug" -i"C:/.../emeter-toolkit/Debug" -i"c:/ti/ccsv6/ccs_base/msp430/include" -i"c:/ti/ccsv6/tools/compiler/msp430_4.3.3/include" -i"c:/ti/ccsv6/ccs_base/msp430/lib/5xx_6xx_FRxx" -i"c:/ti/ccsv6/tools/compiler/msp430_4.3.3/lib" --priority --warn_sections --display_error_number --diag_wrap=off --xml_link_info="mdu_linkInfo.xml" --rom_model -o "mdu.out"  "./src/calibration.obj" "./src/functional_test.obj" "./src/main.obj" "./src/mdu-background.obj" "./src/mdu-foreground.obj" "./src/mdu_console.obj" "./src/mdu_shell.obj" "./src/opto-port.obj" "../lnk_msp430f67691.cmd" -l"C:\..\common.lib" -l"C:\...\IEC60730.lib" -l"libmath.a" -l"libc.a" -l"C:\...\ssm.lib"

It's not immediately obvious what the exact problem is, and I'm not very familiar with how the MSP linker handles interrupt functions, so I'm going to have to get an expert involved.

The only way to work out the problem is to see your project.  Please attach it to your next post.

Thanks and regards,

-George

What exactly do you need? I'm not sure I can send everything, there some IP involved ;-)

We need the entire CCS project.  Are you willing to send it just to me?

Thanks and regards,

-George

I have a working "workspace" and a failing "workspace". The linker command for the working one is of the form

link <options> <include stuff> -o xxx.out -labc.lib def.obj -llibc.lib

The failing one has a different order

link <options> <include stuff> -o xxx.out def.obj -labc.lib -llibc.lib

What knob do I turn to change the order of the "objs" in the linker command?

Carl Hagenmaier said:

What knob do I turn to change the order of the "objs" in the linker command?

Under CCS Properties -> CCS Build -> Link Order you can specify the order objects are passed to the linker.

Use the "Add..." button to specify for which object(s) the order must be controlled.

The "working" version

is the same as the non-working version

Carl Hagenmaier said:

The "working" version

is the same as the non-working version

Your screen shots are not visible.

Do you mean that on the "working" and "non-working" versions the Link Order in the CCS project properties is empty?

The reason is that on a newly created project the Link Order is empty and CCS choses the order files are passed on the linker command line. The issue I have seen is that for reasons not understood, compiling the same project on two different machines can sometimes cause CCS to change the order files are passed on the linker command line.

If the CCS chosen order causes the link to fail, using the Link Order in the CCS project properties to force the order can avoid the link error.

Sorry about the pictures.
The "working" link order is -lcommon.lib, -lssm.lib, "generated linker command files". The "non-working" link order was identical. I removed the line "generated linker command files" from the "non-working" workspace and, lo and behold, it now links correctly!

The question now may be why does the "working" one work?

I think you're onto something. There is some randomness built in somewhere. I have two workspaces on a single machine (PC).

By the way, the "working" version also links correctly if the "generated linker command files" is removed. To be honest, I don't remember why I added that line in the first place - probably copying some example. Perhaps someone can point me to an explanation of what this line does.