boost::asio cross-library link issue
We are using Boost 1.54. The issue i have is a strange problem with the ASIO library. 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? [I hesitate to try forcing strong symbols in our library, since this would break libpcl, due to many functions being inline]. -- View this message in context: http://boost.2283326.n4.nabble.com/boost-asio-cross-library-link-issue-tp468... Sent from the Boost - Users mailing list archive at Nabble.com.
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 library.
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].
I managed to get the compiler options from the two builds. Other than -I options, there are few differences. None of them directly control structure packing. The PCL build has -fPIE (and also a matching -fPIC) and -DBOOST_DISABLE_ASSERTS. Our compile options include -mtune=<arch> (along with a matching -march), --std=c++11, -Dx86_64, and -g (though both have -O3 as well). In typing this, it occurs to me the issue may be the --std=c++11. I will test that ASAP. (I already tested the -DBOOST_DISABLE_ASSERT to no effect). -- View this message in context: http://boost.2283326.n4.nabble.com/boost-asio-cross-library-link-issue-tp468... Sent from the Boost - Users mailing list archive at Nabble.com.
Hi,
The problem is with --std=c++11. I posted similar problem several years
ago and kindly asked to state that asio builds with and
without cxxflags="-std=c++11" create classes with different ABI.
Add cxxflags="-std=c++11" to boost build.
Enjoy,
Slavek
2016-10-03 21:27 GMT+02:00 Stanley Friesen
I managed to get the compiler options from the two builds. Other than -I options, there are few differences. None of them directly control structure packing. The PCL build has -fPIE (and also a matching -fPIC) and -DBOOST_DISABLE_ASSERTS. Our compile options include -mtune=<arch> (along with a matching -march), --std=c++11, -Dx86_64, and -g (though both have -O3 as well).
In typing this, it occurs to me the issue may be the --std=c++11. I will test that ASAP. (I already tested the -DBOOST_DISABLE_ASSERT to no effect).
-- View this message in context: http://boost.2283326.n4. nabble.com/boost-asio-cross-library-link-issue-tp4688567p4688571.html Sent from the Boost - Users mailing list archive at Nabble.com. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Sigh. I thought so. I am having a dickens of a time getting libpcl to compile with the --std=c++11 flag. It seems that libvtk, used heavily by PCL, doesn't like C++11. (We can't compile our library without the flag since we actually use many C++11 features). I will continue to work on this. Thanks, this discussion has at least pointed me in the direction I need to go. -- View this message in context: http://boost.2283326.n4.nabble.com/boost-asio-cross-library-link-issue-tp468... Sent from the Boost - Users mailing list archive at Nabble.com.
On 4 October 2016 at 14:00, Stanley Friesen
Sigh. I thought so. I am having a dickens of a time getting libpcl to compile with the --std=c++11 flag. It seems that libvtk, used heavily by PCL, doesn't like C++11. (We can't compile our library without the flag since we actually use many C++11 features). I will continue to work on this.
Thanks, this discussion has at least pointed me in the direction I need to go.
I have no problem compiling PCL 1.8.0 and VTK 7.0.0 with C++11 support . In the past VTK 6 (not sure on the exact version) and PCL 1.7.2 also worked fine. The VTK wiki seems to indicate VTK 6.1 is compatible with C++11 [1]. Maybe it is an issue with the compiler you're using. Some GCC versions had incomplete C++11 support iirc. [1] http://www.vtk.org/Wiki/VTK/Wrapping_C%2B%2B11_Code
From: Maarten de Vries
Hi,
As far as I can remember, the complete problem with asio ABI compatibility
sits in the asio/detail/atomic_count.hpp and the problem is different size
of std::atomic<long> and boost::detail::atomic_count. You may probably use
BOOST_ASIO_DISABLE_STD_ATOMIC option to make non c++11 ASIO and c++11 ASIO
ABI compatible but I never tested it. We strictly use c++11.
Best Regards,
Slavek
2016-10-04 20:51 GMT+02:00
From: Maarten de Vries
To: boost-users@lists.boost.org, Date: 10/04/2016 01:42 PM Subject: Re: [Boost-users] boost::asio cross-library link issue Sent by: "Boost-users" ------------------------------ On 4 October 2016 at 14:00, Stanley Friesen <*friesens@gdls.com*
> wrote: Sigh. I thought so. I am having a dickens of a time getting libpcl to compile with the --std=c++11 flag. It seems that libvtk, used heavily by PCL, doesn't like C++11. (We can't compile our library without the flag since we actually use many C++11 features). I will continue to work on this. Thanks, this discussion has at least pointed me in the direction I need to go.
I have no problem compiling PCL 1.8.0 and VTK 7.0.0 with C++11 support . In the past VTK 6 (not sure on the exact version) and PCL 1.7.2 also worked fine.
The VTK wiki seems to indicate VTK 6.1 is compatible with C++11 [1].
Maybe it is an issue with the compiler you're using. Some GCC versions had incomplete C++11 support iirc.
-------------------- Quite right, as soon as I got VTK 7.0, the PCL library compiled fine (we only had 5.8 and 6.0 until earlier today). Now my problem is purely with our own library.
VTK 6.0 still had the issue in vtkMath.h where it used 'using namespace std' and then tried to call isinf or isnan. VTK7.0 correctly omits the using directive and calls std::isinf and std::isnan. It is possible this was actually fixed in 6.2 or 6.3.
[1] *http://www.vtk.org/Wiki/VTK/Wrapping_C%2B%2B11_Code[vtk.org]* https://urldefense.proofpoint.com/v2/url?u=http-3A__www.vtk.org_Wiki_VTK_Wrapping-5FC-252B-252B11-5FCode&d=CwMFaQ&c=NGt3eTFKeC-HdGM3w9bJ1g&r=LzeLSpERL2klp086VczAzWzdVVuGtagGieCKbYxUQuw&m=lFTX63uRKR2F6syYk4L52XjxMHeJedZ92ln-U8YvNWs&s=F1uSMeEIrgHyu8p1LHNn_uwWVsaBpUqeq5nTccbDx-U&e= _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists. boost.org_mailman_listinfo.cgi_boost-2Dusers&d=CwICAg&c= NGt3eTFKeC-HdGM3w9bJ1g&r=LzeLSpERL2klp086VczAzWzdVVuGtagGieCKbYxUQuw&m= lFTX63uRKR2F6syYk4L52XjxMHeJedZ92ln-U8YvNWs&s=NDMVH-y9ExBtqecshUXWCShs_ v51sUpH6UIsCG_oMrw&e= ------------------------------ This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. &&
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Thanks. I now have it all working together, /with/ --std=c++11 for everything, including PCL and VTK 7.0.This has been very helpful. -- View this message in context: http://boost.2283326.n4.nabble.com/boost-asio-cross-library-link-issue-tp468... Sent from the Boost - Users mailing list archive at Nabble.com.
participants (5)
-
Edward Diener
-
friesens@gdls.com
-
Maarten de Vries
-
Miloslav Marik
-
Stanley Friesen