Undefined reference to personality?

Tue 15 July 2008

When I was a TA for an undergraduate course in operating systems, I'd often field simple questions as this is sometimes students' first exposure to GNU tools. One or two students invariably came to me with a problem exemplified by the following:


#include "hello.h" 
using namespace std; 
void Hello::print() { 
   cout << "Hello World!" << endl; 


#include <iostream>
class Hello {
   void print();


#include "hello.h"
int main() {
   Hello* h = new Hello();
   return 0;

This code is fine, even by pedantic standards. However, new students often get tripped up:

jldugger@jldugger:~/test $ gcc hello.cc main.cc

several lines worth of linker errors ommited]

main.cc:(.text+0x176): undefined reference to 'std::ios_base::Init::~Init()'

tmp/cc2APvWV.o: In function 'main':

main.cc:(.text+0x195): undefined reference to operator new(unsigned int)'

/tmp/cc2APvWV.o:(.eh_frame+0x11): undefined reference to __gxx_personality_v0'

collect2: ld returned 1 exit status

I stumble on this occasionally too, but it's not hard to diagnose if you know much about C and C++ (for some students this is not the case!). Problems like new being undefined and missing iostreams libraries suggest the linker doesn't understand C++. Google is not always helpful in diagnosing these errors. Some documentation is equally misleading; I recall a time in the past where this was true, and the change has been confusing at times.

The root of the problem is that gcc correctly detects the language type but does not inform the linker stage of compilation to use the standard C++ library. There are a number of fixes possible. One option is to compile with gcc -c , and explicitly link at a later stage. This makes sense for large projects; a Makefile can just compile the changed source and link in the rest of the previous build for faster build times.

An option more suitable for novices is to use g++ explicitly. If you're using .cc files to indicate C++ source code, replace gcc with g++ in your commands and Makefiles. Hopefully readers and Google searcher now understand the problem. And beginning nachOS authors can begin to go on writing deadlocks and race conditions while their compiler chain happily obeys.

Comments !