Re: [Boost-users] Execution problem moving libraries

Subject: Re: [Boost-users] Execution problem moving libraries
From: Lars Viklund (zao_at_[hidden])
Date: 2011-08-01 07:09:14

On Mon, Aug 01, 2011 at 12:56:09PM +0200, Viatcheslav.Sysoltsev_at_[hidden] wrote:
> On Mon, 01 Aug 2011 12:44:42 +0200, Alessandro Candini <candini_at_[hidden]>  
> 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_at_[hidden]