Boost Users :
Subject: Re: [Boost-users] boost::asio cross-library link issue
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-10-03 15:20:56
On 10/3/2016 10:32 AM, Stanley Friesen wrote:
> We are using Boost 1.54. The issue i have is a strange problem with the ASIO
> We have two libraries build using ASIO from Boost 1.54 (libpcl and one of
> our own libraries). For some reason, despite being built with the same
> version of boost, the layout of class task_io_service differs between the
> two libraries. The member function instantiations are in the libraries as
> weak symbols, so we do not get a link error, but which version of each
> function that is called from any given place is unpredictable, and varies
> when we change out own code. In particular, at least op_queue_ and all
> following members have offsets that differ by 8 bytes (the size of a 64-bit
> pointer) between the two builds. The result is that sometimes the op_queue
> back pointer is corrupted (by the other version setting stopped_), or the
> stop flag is not seen because it was set by the other build. The result is
> either that run() returns immediately without doing anything, or out
> application crashes from trying to dereference an invalid pointer. (Often
> what is supposed to be a NULL back pointer is set to 1, which does not
> compare equal to NULL).
> I have looked for conditionally compiled elements in task_io_service,
> op_queue, and epoll_reactor with no luck. I can see no reason the two
> library builds should end up with different class layouts.
> So, does anybody have any clue what might be happening here? Or how to go
> about fixing the problem?
Sometimes structure packing can be set for a compiler and if it is
different between modules you will have the problems you are encountering.
> [I hesitate to try forcing strong symbols in our library, since this would
> break libpcl, due to many functions being inline].
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net