2013-02-08 11 views
5

Mam kompilacji program w C++ przy użyciu wiersza poleceniabłąd łącznik „relokacja R_X86_64_PC32 przed nieokreślonym symbolem” pomimo kompilacji z -fPIC

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

a następnie starać się obiekt udostępniony poprzez

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

To zawsze działało. Ale dziś mam:

/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 

symbol _ZTVN12_GLOBAL__N_111handle_baseE de-Mangles do vtable for (anonymous namespace)::handle_base (handle_base jest klasą polimorficzny zdefiniowane w anonimowej przestrzeni nazw w prog.cc i tak nie nazywają dynamic_cast<handle_base>().)

I "Używam gcc w wersji 4.7.0 (GCC) i GNU ld (GNU Binutils; openSUSE 11.1) 2.19. Czy ktokolwiek może pomóc (sugerować rozwiązania [inne niż robienie bez wspólnego obiektu lub dynamic cast])?

+0

Wygląda na to, że zapomniałeś * zdefiniować * jakąś * metodę wirtualną * dla 'handle_base'. –

+0

Czy nie musisz ** link ** również z -fPIC? –

+0

@ H2CO3 Nie (próbowałem w każdym razie: nie robi różnicy) – Walter

Odpowiedz

1

Właśnie wpadłem na coś podobnego podczas aktualizacji do Ubuntu 14.04. Musiałem dodać funkcję -fkeep-inline do pliku źródłowego, który zdefiniował symbol "brakujący". Nie wiem, czy twój problem jest podobny.

0

Po prostu musisz ukryć domyślną widoczność swojej klasy bazowej (handle_base). Możesz to zrobić przez -

#define VISIBILITY __attribute__((visibility("hidden"))) 
class VISIBILITY handle_base; 
+0

(1) Myślę, że '__attribute __ ((widoczność (" ukryty "))) jest niestandardowe i nie jest obsługiwane w tej formie przez wszystkie kompilatory. (2) dlaczego to rozwiązałoby problem? – Walter

+0

1. Nigdzie nie widzę, że jest to niestandardowe. Powiem jednak, że jest napisane: "Najlepiej nie używać opcji widoczności dla programów zorientowanych obiektowo w C++ z powodu niebezpieczeństwa generowania błędów w środowisku wykonawczym, które są trudne do debugowania. Zamiast tego należy skorzystać z nieodłącznych cech obiektu C++. zorientowane programy, takie jak enkapsulacja, przestrzenie nazw, dziedziczenie i inne cechy. " 2. Jak https://gc.gnu.org/wiki/Visibility mówi, nie. 4 może być twoją sprawą. –

+1

@Robelsharma Wszystkie '__attribute__'s są rozszerzeniami GCC. [Dokumentacja GCC] (https://gc.gnu.org/onlinedocs/gcc/Function-Attributes.html) wyraźnie stwierdza, że ​​atrybutami tymi są "Rozszerzenia C". –

Powiązane problemy