5

I'm compiling a c++ program using the command line

g++ -c prog.cc -std=c++11 -march=native -fPIC -fopenmp

and then try to make a shared object via

g++ prog.o -shared -fopenmp -o lib/libprog.so

This has always worked. But today I get:

/usr/bin/ld: prog.o: relocation R_X86_64_PC32 against undefined symbol 
  `_ZTVN12_GLOBAL__N_111handle_baseE' can not be used when making a shared
  object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

The symbol _ZTVN12_GLOBAL__N_111handle_baseE de-mangles to vtable for (anonymous namespace)::handle_base (handle_base is a polymorphic class defined in the anonymous namespace in prog.cc and yes I do call dynamic_cast<handle_base>().)

I'm using gcc version 4.7.0 (GCC) and GNU ld (GNU Binutils; openSUSE 11.1) 2.19. Can anybody help (suggest solutions [other than doing without shared object or the dynamic cast])?

Walter
  • 44,150
  • 20
  • 113
  • 196
  • Looks like you have forgotten to *define* some *virtual method* for `handle_base`. – Anton Kovalenko Feb 08 '13 at 18:47
  • Don't you have to **link** with -fPIC as well? –  Feb 08 '13 at 18:48
  • @H2CO3 No. (I tried anyway: makes no difference) – Walter Feb 08 '13 at 18:49
  • @AntonKovalenko If the method is pure virtual, then you don't defined it. `handle_base` only as one pure virtual method. Making that just virtual and giving a function body does not help. – Walter Feb 08 '13 at 18:51
  • Does "g++ -shared prog.cc -std=c++11 -march=native -fPIC -fopenmp -o lib/libprog.so" have the same problem? –  Feb 08 '13 at 19:26
  • Any luck with this problem? I am stuck with a similar one while trying to compile mozilla JS on my centos 5.3 64 bit machine. – Abhishek Nov 22 '13 at 07:30
  • @Abhishek oops. this has been sorted long ago, but don't ask me how. I now use gcc 4.8, so that may have helped, but perhaps it was a missing library ?? Perhaps I avoided the `dynamic_cast<>()` (most likely). – Walter Nov 22 '13 at 18:21
  • We are getting almost the same error and would really like to find a solution. Upgrading the compiler is not an option in our case. – taranaki Feb 12 '14 at 20:44

2 Answers2

1

I just ran into something similar when upgrading to ubuntu 14.04. I had to add -fkeep-inline-functions to the source file that defined the 'missing' symbol. No idea if your problem is similar.

Dan Kegel
  • 559
  • 5
  • 11
0

You just need to make the default visibility hidden for your base class(handle_base). You can do this by -

#define VISIBILITY __attribute__((visibility("hidden")))
class VISIBILITY handle_base;
Robel Sharma
  • 964
  • 1
  • 11
  • 26
  • (1) I think the `__attribute__((visibility("hidden")))` is non-standard and not supported in this form by all compilers. (2) why would this solve the problem? – Walter Aug 28 '14 at 12:41
  • 1. I don't see anywhere that it says it non-standard. But I will say it says -- "It is best not to use the visibility option for C++ object-oriented programs because of the danger of generating runtime errors that are difficult to debug. Instead, take advantage of the inherent characteristics of C++ object-oriented programs, such as encapsulation, namespaces, inheritance, and other characteristics." 2. As https://gcc.gnu.org/wiki/Visibility says , the no. 4 may be your case. – Robel Sharma Aug 29 '14 at 05:02
  • 1
    @Robelsharma All `__attribute__`s are GCC extensions. [GCC documentation](https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html) clearly states that these attributes are "C Extensions." – Timothy Gu Dec 29 '14 at 02:37