Find the line of source code that causes the undefined reference error

Question

sooner or later, when programming in C / C ++, everyone came across an "undefined error reference".

Often this happens due to the lack of libraries, and most of these errors are fixed within a few seconds, contacting the missing libraries. However, when, for example, templates with separate files are used for declaration and implementation, you can get an undefined link caused by "unintentional" template creation. Unfortunately, all the information that we now receive is an instance of an "undefined reference error", with no possible hints for a reason, such as line numbers of callers, etc.

What interests me is: Is there an easy way to determine the actual line (s) of the source code that calls the function / template that causes the undefined link error?

Answer 1

As I mentioned in my answer to this question , is it easy to get the line number that causes the link error depends on whether the compiler emitted all the necessary information.

To begin with, these are the cases that I have encountered, which leads to the behavior that you see:

• Compiler emitting erroneous debugging information (Solaris studio 12.3 with debugging / optimization under certain circumstances)
• Executing a destructor for an object that goes out of scope
• Code inserted by compiler:
  • stack protection
  • disinfectants
  • other tools that enter code for debugging or profiling

---

What I will suggest for tracking can help if you have a link error resembling:

asdf.o: In function `whatever': asdf.o(.text+0x1238): undefined reference to `fdsa' 

... because at least you have an address for work.

First try addr2line :

 ~ addr2line -e asdf.o 0x1238 # If it works, you'll get: asdf.cc:N # If it doesn't work, you'll get: ??:? 

Otherwise try objdump :

 ~ objdump --dwarf=decodedline asdf.o asdf.o: file format elf64-x86-64 Decoded dump of debug contents of section .debug_line: CU: asdf.cc: File name Line number Starting address asdf.cc 1 0x1234 asdf.cc 3 0x1254 asdf.cc 5 0x1274 

In the fully fabricated example I cited here, there is no entry in the .debug_line corresponding to 0x1238 (the address is in the linker error), so it can be compiler magic (for example, additional code added by something like a stack protector or sanitizer), or, I hope, it is connected with what happens on the 1/3 lines, since the address is between these two lines.

If this does not give you enough opportunities to continue: when I wanted a little more, I did the following:

• Insert a link flag to stop it from being dismantled to get a distorted character.
• Compile the object file, but instead it will generate an assembly
• Build Search for Distorted Character

Assuming the assembly is annotated enough, it shouldn't be terribly difficult to match the missing character + information from objdump + assembly and at least get a fix in the line of code to run the rest of your search (assuming you still have more holes for rabbits, as is often the case with STL).