Execution problem moving libraries
Hi everyone. I get a very tricky error with boost.thread. I can compile and execute perfectly a C++ program with the following comand line: g++ -Wall -fPIC -pedantic -g -O3 -DDEBUG -march=native -std=c++0x -lboost_thread -o myExecutable myExecutable.cpp But I have to move this software into another machine, and I thought it was possible to take dynamic libraries with it, in order to properly link them to the executable. I have a structure like the following: package | bin |- myExecutable etc |- libboost_thread.a |- libboost_thread.so -> libbost_thread.so.1.42.0 `- libboost_thread.so.1.42.0 And performing a proper export of LD_LIBRARY_PATH, it seems I obtain a correct link: ldd myExecutable ... libboost_thread.so.1.42.0 => ../etc/libboost_thread.so.1.42.0 (0x002cd000) ... But when I try to execute my software, I obtain the following error: /home/user/myExecutable symbol lookup error: /home/user/myExecutable: undefined symbol: _ZTIN10__cxxabiv115__forced_unwindE Do you have an idea of why this occurs? Have I to compile boost libraries in an uncommon way to make this situation work? Thank you. -- Alessandro Candini MEEO S.r.l. Via Saragat 9 I-44122 Ferrara, Italy Tel: +39 0532 1861501 Fax: +39 0532 1861637 http://www.meeo.it ======================================== "ATTENZIONE:le informazioni contenute in questo messaggio sono da considerarsi confidenziali ed il loro utilizzo è riservato unicamente al destinatario sopra indicato. Chi dovesse ricevere questo messaggio per errore è tenuto ad informare il mittente ed a rimuoverlo definitivamente da ogni supporto elettronico o cartaceo." "WARNING:This message contains confidential and/or proprietary information which may be subject to privilege or immunity and which is intended for use of its addressee only. Should you receive this message in error, you are kindly requested to inform the sender and to definitively remove it from any paper or electronic format."
On 08/01/2011 09:39 AM, Alessandro Candini wrote:
But when I try to execute my software, I obtain the following error: /home/user/myExecutable symbol lookup error: /home/user/myExecutable: undefined symbol: _ZTIN10__cxxabiv115__forced_unwindE
That symbol is probably from libstdc++ or from another gcc-specific library.
So it'is not related to Boost? How can I solve it? On 01/08/11 10:28, Mathias Gaunard wrote:
On 08/01/2011 09:39 AM, Alessandro Candini wrote:
But when I try to execute my software, I obtain the following error: /home/user/myExecutable symbol lookup error: /home/user/myExecutable: undefined symbol: _ZTIN10__cxxabiv115__forced_unwindE
That symbol is probably from libstdc++ or from another gcc-specific library.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Alessandro Candini MEEO S.r.l. Via Saragat 9 I-44122 Ferrara, Italy Tel: +39 0532 1861501 Fax: +39 0532 1861637 http://www.meeo.it ======================================== "ATTENZIONE:le informazioni contenute in questo messaggio sono da considerarsi confidenziali ed il loro utilizzo è riservato unicamente al destinatario sopra indicato. Chi dovesse ricevere questo messaggio per errore è tenuto ad informare il mittente ed a rimuoverlo definitivamente da ogni supporto elettronico o cartaceo." "WARNING:This message contains confidential and/or proprietary information which may be subject to privilege or immunity and which is intended for use of its addressee only. Should you receive this message in error, you are kindly requested to inform the sender and to definitively remove it from any paper or electronic format."
On Mon, 01 Aug 2011 12:44:42 +0200, Alessandro Candini <candini@meeo.it> wrote:
But when I try to execute my software, I obtain the following error: /home/user/myExecutable symbol lookup error: /home/user/myExecutable: undefined symbol: _ZTIN10__cxxabiv115__forced_unwindE
That symbol is probably from libstdc++ or from another gcc-specific library.
So it'is not related to Boost?
How can I solve it?
Crosscompile with target gcc/libstdc++ on host machine, or save the pain, compile on the target (or similar) machine. Theoretically you can bind libstdc++ statically, but I never seen that used, so it is probably much bigger pain ;)
On Mon, Aug 01, 2011 at 12:56:09PM +0200, Viatcheslav.Sysoltsev@h-d-gmbh.de wrote:
On Mon, 01 Aug 2011 12:44:42 +0200, Alessandro Candini <candini@meeo.it> wrote:
But when I try to execute my software, I obtain the following error: /home/user/myExecutable symbol lookup error: /home/user/myExecutable: undefined symbol: _ZTIN10__cxxabiv115__forced_unwindE
This is typically due to the loader on the target system pulling in an ABI-incompatible library of the same name. There's some protections against things like this in GLIBC by adding named labels they look for when loading, but it's not overly wide-spread in other libraries. In a perfect world, library versioning should be such that it's impossible to get the wrong library version pulled in. You might want to feed your exectuable to ldd(1) to see how the loader resolves the libraries needed on your two systems.
That symbol is probably from libstdc++ or from another gcc-specific library.
How can I solve it?
Crosscompile with target gcc/libstdc++ on host machine, or save the pain, compile on the target (or similar) machine. Theoretically you can bind libstdc++ statically, but I never seen that used, so it is probably much bigger pain ;)
In the Windows world where binary deployment is the usual way of distributing software, it's common knowledge that you need to deploy the runtime and all libraries needed by an application, as you cannot rely on that a compatible runtime being installed on the target system. This tends to be largely ignored or unknowng to developers on systems where the primary mode of operation is compiling things against the blessed version present on the machine you're deploying to. There's some efforts out there to provide a reliable baseline of libraries and compilers you can use to be able to build and deploy dynamically linked applications on such systems, like the LSB initiative on Linux. If the compiler and library versions of the LSB are not up to your demands, the only realistic choice is to static-link everything and pray for the best. -- Lars Viklund | zao@acc.umu.se
On 01/08/2011 13:09, Lars Viklund wrote:
If the compiler and library versions of the LSB are not up to your demands, the only realistic choice is to static-link everything and pray for the best.
Or ship your executable along with the shared libraries it needs, but that can cause other problems.
participants (4)
-
Alessandro Candini -
Lars Viklund -
Mathias Gaunard -
Viatcheslav.Sysoltsev＠h-d-gmbh.de