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, 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 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