• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 53 subscribers
  • Views 1029 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/TMS320C6657: undefined symbol operator delete

David Pardessus
Intellectual 290 points

Part Number: TMS320C6657

Tool/software: TI C/C++ Compiler

Hello,

I have a project (CCSv9.0.1, compiler 8.3.2) which links with some libs, and the linker is not satisfied :

undefined                              first referenced                                                                     
  symbol                                    in file     

operator delete (void *, unsigned int) mylib.lib<myobj.obj>

Analysing lib code didn't give me a clue (abuse of object oriented programmation ;-) ) so I tried to call nm6x on the lib : nm6x.exe -u -l mylib.lib

But the output doesn't mention a undefined symbol delete

[0]     |0x00000000|0|LOCL |NONE |DFLT |UNDEF |
[542]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |_Z23defaultAssertDbgHandlerPKcjS0_S0_
[588]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |_Z24defaultAssertWarnHandlerPKcjS0_S0_
[545]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |_Z25defaultAssertFatalHandlerPKcjS0_S0_
[560]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |_ZN19OE_C_EvtServerProxy10InitializeEv
[580]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |_ZN19OE_C_EvtServerProxy10s_InstanceE
[557]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |_ZN28OE_C_MemoryAllocator_DynamicC1Ev
[570]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |_ZN28OE_C_MemoryAllocator_DynamicD1Ev
[558]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |_ZTVN10__cxxabiv117__class_type_infoE
[582]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |_ZdlPvj
[559]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |__cxa_atexit
[579]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |__cxa_guard_acquire
[566]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |__cxa_guard_release
[584]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |__dso_handle
[0]     |0x00000000|0|LOCL |NONE |DFLT |UNDEF |

Can someone help me to hunt this so called undefined delete ?

Regards,

David

  • 0
    TI__Guru**** 252770 points

    It's this one ...

    David Pardessus said:
    [582]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |_ZdlPvj

    I know, clear as mud.  Use the demangler dem6x to see it.  Something like this ...

    % nm6x -u -l mylib.lib | dem6x -q --abi=eabi
[0]     |0x00000000|0|LOCL |NONE |DFLT |UNDEF |
[542]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |defaultAssertDbgHandler(const char *, unsigned int, const char *, const char *)
[588]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |defaultAssertWarnHandler(const char *, unsigned int, const char *, const char *)
[545]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |defaultAssertFatalHandler(const char *, unsigned int, const char *, const char *)
[560]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |OE_C_EvtServerProxy::Initialize()
[580]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |OE_C_EvtServerProxy::s_Instance
[557]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |OE_C_MemoryAllocator_Dynamic::OE_C_MemoryAllocator_Dynamic()
[570]   |0x00000000|0|GLOB |NONE |HIDN |UND EF |OE_C_MemoryAllocator_Dynamic::~OE_C_MemoryAllocator_Dynamic()
[558]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |Virtual function table for __cxxabiv1::__class_type_info
[582]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |operator delete (void *, unsigned int)
[559]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |__cxa_atexit
[579]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |__cxa_guard_acquire
[566]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |__cxa_guard_release
[584]   |0x00000000|0|GLOB |NONE |HIDN |UNDEF |__dso_handle
[0]     |0x00000000|0|LOCL |NONE |DFLT |UNDEF |

    If you inspect the assembly code for the object file named by the linker, search for _ZdlPvj.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 290 points

    Thanks for the demangler !

    Regards,

    David