Boost C++ Libraries: Ticket #4594: Boost exception classes do not have GCC default visibility

attachment set

Wed, 25 Aug 2010 19:25:47 GMT

attachment → boost_visibility.tar

Isolated reproduction code.

Wed, 08 Sep 2010 18:05:20 GMT

Would it be possible to get an update as to the status of this bug?

type changed

Tue, 07 Dec 2010 20:08:33 GMT

type Bugs → Patches

status changed; resolution set

Emil Dotchevski — Sat, 12 Feb 2011 00:12:28 GMT

status new → closed
resolution → fixed

Dimitrij Drus — Tue, 24 May 2011 07:18:15 GMT

I just moved to the 1.46.1 version of boost. It still lacks the visibility support for boost::exception. The trunk has corresponding adjustments, which however are not complete. Within the exception.hpp there is a forward declaration of the exception class. Without surrounding this forward declaration with GCC visibility pragmas too, the boost::exception can't be catched if throwed across the shared lib boundaries.

The behaviour was observed on Ubuntu 10.04 with gcc version 4.4.3.

Emil Dotchevski — Tue, 24 May 2011 22:56:53 GMT

Thanks for the feedback Dimitrij.

Have you verified that surrounding the forward declaration with visibility pragmas solves the problem? I don't have an easy way to test this so I'd appreciate a patch that is tested to work.

Tue, 14 Jun 2011 10:12:18 GMT

Yes. Catching boost::exception thrown over the shared library boundaries is only possible after surrounding the forward declaration with the visibility pragmas. Patch is attached.

One can use the test attached by Jonathan to verify this. Jonathan, however, expects the class boost::exception_detail::clone_base be exported (surrounded with gcc visibility pragmas) too, that's why corresponding test cases fail.

Regards Dimitrij

attachment set

Tue, 14 Jun 2011 10:14:21 GMT

attachment → exception.patch

Patch for boost/exception/exception.hpp file

Tue, 14 Jun 2011 10:20:08 GMT

If one has troubles launching Jonathan's test, one should add -Wl,-rpath,'$ORIGIN' to the last line of the make file. In my case the libboost_visibility.so was not found without this modification.

I hope it is not too late to apply the path for the coming release.

Regards Dimitrij

attachment set

Tue, 14 Jun 2011 20:32:37 GMT

attachment → boost_visibility.2.tar

Updated test case, including showing the fact that error_info/get_error_info also have symbol visibility issues.

Tue, 14 Jun 2011 20:36:19 GMT

It's not enough to ensure that boost::exception, boost::exception_detail::clone_base, and boost::unknown_exception have default symbol visibility on GCC. It appears that boost::error_info also needs to be decorated with default visibility. Otherwise, calls to get_error_info on exceptions propagated across library boundaries will always return NULL, rendering boost::exception essentially useless.

Tue, 14 Jun 2011 23:31:01 GMT

Why should one be interested in catching boost::exception_detail::clone_base? Its just an internal detail. Either one want catch an own exception or the boost one.

Wed, 15 Jun 2011 13:59:40 GMT

You aren't interested in catching it directly. However, the implementation of boost::current_exception re-throws the exception and catches it as exception_detail::clone_base to determine if it's "cloneable". If exception_detail::clone_base doesn't have default visibility, boost::current_exception doesn't work if the exception originated from a different library.

mark.schisler@… — Fri, 08 Jul 2011 14:56:15 GMT

This bug is actually causing X-Code 4.01 and LLVM/GCC 4.2 to not link Boost 1.46.1 correctly with or without symbols hidden. I ended up with the following linker error.

ld: bad codegen, pointer diff in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >::rethrow() constto global weak symbol vtable for boost::exceptionfor architecture i386
collect2: ld returned 1 exit status

I'm not sure if it's a minimal solution or not, but I was able to resolve the problem by applying a fix similar to what was suggested by Jonathan. I enclosed exception/exception.hpp and exception/detail/exception_ptr.hpp in the following guards:

#if defined(__GNUC__)
# if (__GNUC__ == 4 && __GNUC_MINOR__ >= 1) || (__GNUC__ > 4)
#  pragma GCC visibility push (default)
# endif
#endif
#if defined(__GNUC__)
# if (__GNUC__ == 4 && __GNUC_MINOR__ >= 1) || (__GNUC__ > 4)
#  pragma GCC visibility pop
# endif
#endif

status, version changed; cc set; resolution deleted

Fri, 15 Jul 2011 17:31:16 GMT

cc ejt@… added
status closed → reopened
version Boost 1.40.0 → Boost 1.47.0
resolution fixed

I confirm Mark's error, I see the same error also with Boost 1.47 (building Ogre3D on Xcode 4, gcc 4.2.1).

I notice some visibility stuff was added to exception.hpp, but this is not enough. Apparently, error_info_injector and clone_impl (in exception/exception.hpp) both need to be wrapped with visibility pragmas in order to fix that error.

Further, thread/exceptions.hpp also needs to be wrapped with visibility, or you will get:

ld: bad codegen, pointer diff in boost::thread_exception::thread_exception()to global weak symbol vtable for boost::thread_exceptionfor architecture i386

attachment set

Fri, 15 Jul 2011 17:32:10 GMT

attachment → thread_visibility.diff

Patch to support visibility with thread module

Fri, 15 Jul 2011 17:37:38 GMT

Also, I'm not confident about the current visibility settings in exception. Will there be further linkage issues for other projects which use different features of boost?

Perhaps the visibility pragmas should be wrapped around the all of the header contents for exception.hpp and exception_ptr.hpp as Mark suggested to ensure this isn't an ongoing issue. (This doesn't look to be an excessive amount of additional visible symbols, worth the margin of safety?)

Emil Dotchevski — Fri, 15 Jul 2011 17:50:25 GMT

I am against making all classes visible. There aren't that many types that need to be visible. The first thing we need is a formal test in libs/exception/test. Can someone help writing this, so I can see all failures that need to be fixed on various platforms?

ian.esten@… — Mon, 12 Dec 2011 22:12:37 GMT

I was having this problem with a dylib using boost::thread that linked to another dylib using boost::thread. The thread_visibility.diff patch solved the problem for me.

Emil Dotchevski — Thu, 22 Dec 2011 21:31:59 GMT

I've committed only the Boost Exception part of thread_visibility.diff patch (that is, without the Boost Thread part of it.) Out of curiosity, do we really need the error_info_injector type to be visible? I don't understand why it is needed, but I haven't tested.

Anyone care to add a test program to verify that visibility settings work across different platforms?

shreyas.bme@… — Sat, 28 Jan 2012 03:37:09 GMT

Hi,

I am getting following error. Please guide me.

Boost version: 1_45_0

/ERROR LOGS/

ld: bad codegen, pointer diff in boost::signals::connection::connection(boost::signals::connection const&)to global weak symbol boost::detail::spinlock_pool<1>::pool_ for architecture armv7 collect2: ld returned 1 exit status Command /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++-4.2 failed with exit code 1

Emil Dotchevski — Sat, 28 Jan 2012 04:09:05 GMT

Um, this doesn't seem to have anything to do with ticket 4594?

shreyas.bme@… — Sat, 28 Jan 2012 05:28:37 GMT

Nope. Do you know solution? Please let me know.

status changed; resolution set

Emil Dotchevski — Tue, 19 Jun 2012 23:57:56 GMT

status reopened → closed
resolution → fixed

I'm closing this, please reopen if visibility on some platform(s) is a problem.

anonymous_but_0X — Mon, 20 Oct 2014 17:29:49 GMT

Hello everyone,

hope you had a good weekend, I am afraid the problem is back, moving from LLVM xcode 4.4.1 to Apple LLVM 6.0 (10.9), I got it again, but I think I am not the only one.

"boost::exception_detail::error_info_injector <boost::gregorian::bad_month>::error_info_injector(boost::exception_detail::error_info_injector<boost::gregorian::bad_month> const&) to global weak symbol vtable for boost::exception_detail::error_info_injector<boost::gregorian::bad_month> means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings."

the mysterious thin, and I think I need to question Ted Kremenek, because with the previous LD/compiler everything was fine according to their static analyzer, moving to the next version tool makes it incompatible, weak symbols that's just a convention how you stored them, Kremenek should use its magic wand and give solution.r

Sun, 11 Feb 2018 09:24:16 GMT

Hi:

i worked with boost1_58_0,it accors some error by compiled.please give me some suggest,thanks.

errors:

boost/asio/handler_type.hpp:20 boost/asio/detail/push_options.hpp:71:11: error :'pragma' is not allowed here

#pragma GCC visibility push(default)

boost/asio/detail/pop_options.hpp:71:11: error :expected decalration before end of line

Emil Dotchevski — Sun, 11 Feb 2018 19:48:28 GMT

Which compiler?