2012-04-14 10 views
1

Ich versuche, eine proprietäre SDK von Sixense (Treiber für einen Gamecontroller) zu verwenden. Es sieht so aus, als würden sie statisch auf boost :: thread verlinken. Meine Anwendung und einige ihrer Abhängigkeiten verwenden auch boost :: thread, und ich bekomme einen segfault.Segfault wegen Namenskollision von Third-Party-Bibliothek

Program received signal SIGSEGV, Segmentation fault. 
0x00007ffff7bd1bb5 in boost::thread::start_thread()() from /usr/lib/libboost_thread.so.1.42.0 
(gdb) bt 
#0 0x00007ffff7bd1bb5 in boost::thread::start_thread()() from /usr/lib/libboost_thread.so.1.42.0 
#1 0x00007ffff79869bb in USBDetector::start_hotplug_thread()() 
    from /home/joschu/Downloads/sixenseSDK_linux_OSX/samples/linux_x64/sixense_simple3d/libsixense_x64.so 
#2 0x00007ffff7986c7e in USBDetector::start(std::vector<unsigned int, std::allocator<unsigned int> >, std::vector<std::vector<unsigned int, std::allocator<unsigned int> >, std::allocator<std::vector<unsigned int, std::allocator<unsigned int> > > >, std::vector<unsigned int, std::allocator<unsigned int> >)() from /home/joschu/Downloads/sixenseSDK_linux_OSX/samples/linux_x64/sixense_simple3d/libsixense_x64.so 
#3 0x00007ffff7987298 in USBManagerLinux::start(std::vector<unsigned int, std::allocator<unsigned int> >, std::vector<std::vector<unsigned int, std::allocator<unsigned int> >, std::allocator<std::vector<unsigned int, std::allocator<unsigned int> > > >, std::vector<unsigned int, std::allocator<unsigned int> >, int)() from /home/joschu/Downloads/sixenseSDK_linux_OSX/samples/linux_x64/sixense_simple3d/libsixense_x64.so 
#4 0x00007ffff79842f3 in USBManager::start(std::vector<unsigned int, std::allocator<unsigned int> >, std::vector<std::vector<unsigned int, std::allocator<unsigned int> >, std::allocator<std::vector<unsigned int, std::allocator<unsigned int> > > >, std::vector<unsigned int, std::allocator<unsigned int> >, int)() from /home/joschu/Downloads/sixenseSDK_linux_OSX/samples/linux_x64/sixense_simple3d/libsixense_x64.so 
#5 0x00007ffff79a03d6 in DriverMain::start(int)() 
    from /home/joschu/Downloads/sixenseSDK_linux_OSX/samples/linux_x64/sixense_simple3d/libsixense_x64.so 
#6 0x00007ffff79a1e32 in sixenseInit() 
    from /home/joschu/Downloads/sixenseSDK_linux_OSX/samples/linux_x64/sixense_simple3d/libsixense_x64.so 
#7 0x0000000000400d0d in main() at /home/joschu/bulletsim/src/hydra/hi.cpp:6 

Wenn ich um die Art und Weise schalten das Projekt verknüpft ist, fand ich, dass meine anderen Bibliotheken sixense der boost :: Thread ruft am Ende.

Gibt es eine Möglichkeit, dieses Problem zu umgehen?

Antwort

2

Es sieht aus wie sie statisch aufzuladen verbinden :: thread

Sie nicht sagen, was sie verbunden boost::thread in statisch. Ich nehme an, dass sie es in libsixense_x64.so verbunden haben.

Es gibt mehrere allgemeine Möglichkeiten, den Namen Kollision zu vermeiden:

  1. die sdk Entwickler stellen ihre Tat zu säubern. Was sie sollte getan haben, ist Link Boost in statisch und verstecken diese Tatsache, z. durch kompilieren mit -visibility = versteckt, und exportiert nur ihre vorgesehene Schnittstelle, anstatt alles zu exportieren (was ist, was es klingt, taten sie).
  2. Wenn Sie nicht die SDK-Entwickler zum Aufräumen zwingen können, können Sie ihre SDK-Bibliothek über dlopen mit RTLD_LOCAL Bindung laden. Dies macht es ein wenig schwierig, den SDK zu verwenden, sollte aber seine Symbole aus dem Namespace des globalen dynamischen Linkers behalten.
  3. Schließlich der Vollständigkeit halber: Wenn Sie unter Linux sind (was Ihre Nachricht suggeriert, aber nicht angibt), können Sie dlmopen verwenden, um den SDK in einen vollständig separaten dynamischen Linker-Namespace zu laden. Ich sehe keinen Vorteil gegenüber Option 2 und es gibt mehrere Nachteile.
+0

Das stimmt, sie haben es in libsixense_x64.so verbunden, die alles exportiert. Danke für die gründliche Antwort. – John