Boost C++ Libraries: Ticket #2114: Patch for export symbols from shared library

attachment set

anonymous — Mon, 14 Jul 2008 06:02:24 GMT

attachment → dso_export.patch

patch file

Jürgen Hunold — Wed, 10 Sep 2008 17:00:31 GMT

One example of missing visibility support is #2309.

anonymous — Fri, 05 Dec 2008 14:40:58 GMT

I don't see BOOST_DSO_EXPORT_EXCEPTION and BOOST_DSO_IMPORT_EXCEPTION used anywere. What does it means?

owner set

arhipjan@… — Fri, 05 Dec 2008 16:00:14 GMT

owner set to Dave Abrahams

anonymous — Fri, 05 Dec 2008 16:22:08 GMT

Replying to anonymous:

I don't see BOOST_DSO_EXPORT_EXCEPTION and BOOST_DSO_IMPORT_EXCEPTION used anywere. What does it means?

These macroses are intended for re-exporting symbols from shared libraries.
(This use case - re-exporting - usually is only applied to exceptions ).
You can find more details about exceptions that reside in shared libraries
in this message:
http://thread.gmane.org/gmane.comp.lib.boost.devel/177304/focus=177414
Yes, BOOST_DSO_EXPORT/IMPORT_EXCEPTION are not used anywhere, but they should.
So, patch should be updated. But at first,
exception re-exporting policy should be discussed with boost community

attachment set

arhipjan@… — Thu, 11 Dec 2008 13:55:44 GMT

attachment → boost_build_symbol_export.patch

patch updated: boost-build part

attachment set

anonymous — Thu, 11 Dec 2008 13:57:15 GMT

attachment → boost_symbol_export.patch

patch updated: boost part

Jürgen Hunold — Fri, 29 May 2009 07:10:39 GMT

I have attached an improved version of this path. Features:

no new headers needed, everything is in the current config headers
clearer macro names

Vladimir Prus — Fri, 29 May 2009 07:45:30 GMT

Jürgen,

what is the meaning of BOOST_SYMBOL_FORWARD_EXPORT and BOOST_SYMBOL_FORWARD_IMPORT and BOOST_EXCEPTION_EXPORT and BOOST_EXCEPTION_IMPORT? Are there cases where special import/export is necessary?

Jürgen Hunold — Fri, 29 May 2009 13:59:10 GMT

Hi Dave, those two are used in Boost.Python:

python/detail/config.hpp:73:#define BOOST_PYTHON_DECL_FORWARD BOOST_SYMBOL_FORWARD_EXPORT

python/detail/config.hpp:74:#define BOOST_PYTHON_DECL_EXCEPTION BOOST_EXCEPTION_EXPORT

I simply replaced the existing logic. I thought that you should know what they do. And please verify that I'm doing things right for Boost.Python. And Boost.Serialization uses some strange logic for Borland. Files:

boost/serialization/config.hpp boost/archive/detail/decl.hpp

I hope that helps

arhipjan@… — Fri, 29 May 2009 15:01:22 GMT

2 jhunold:
Comments on updated patch

Why do you mind using separate headers?
win32.hpp: are you sure all the compilers (e.g., Intel) supports dllexport?
Strange diff in gcc.hpp: #define BOOST_NO_CHAR16_T

Originally, one of the ideas of BOOST_SYMBOL_XXX macro was to save typing, i.e.:

#if defined(BOOST_HAS_DECLSPEC)
#   if defined(BOOST_THREAD_BUILD_DLL)
#       define BOOST_THREAD_DECL __declspec(dllexport)
//...
becomes:
//...
#if defined(BOOST_THREAD_BUILD_DLL)
#  define BOOST_THREAD_DECL BOOST_SYMBOL_EXPORT

Regards

Jürgen Hunold — Fri, 29 May 2009 17:48:51 GMT

First, for longer discussions I prefer threaded Mails ;-)) I'm not strictly against separate headers, but the macros just fit into the existing headers. No need to introduce another one.

win32.hpp did just #define BOOST_HAS_DECLSPEC for all compilers including Intel/Windows. I can not test Intel/Linux, so no changes for this one. The only thing I am not sure are the strange things Boost.Serialization does for Borland what no other library does. So I skipped serialization,too.

gcc.hpp: Thanks for pointing this out, seems like a merge relict. Beman added the tr1 macros at the same place.

And finally I decided to make the patches small and remove the code duplication in the libraries later. The complete patches are more difficult to understand.

attachment set

Jürgen Hunold — Fri, 29 May 2009 17:55:50 GMT

attachment → boost_visibility.diff

Fixed patch using existing headers

component changed

viboes — Sat, 06 Jun 2009 15:04:16 GMT

component None → config

bschaeling — Thu, 06 Aug 2009 13:31:32 GMT

It would be nice if support for Sun CC was added, too. According to http://developers.sun.com/solaris/articles/symbol_scope.html __declspec(dllimport) maps to __global and __declspec(dllexport) to the __symbolic specifier.

owner changed

anonymous — Thu, 06 Aug 2009 13:52:20 GMT

owner changed from Dave Abrahams to John Maddock

John Maddock — Thu, 06 Aug 2009 16:16:43 GMT

Is this nearly ready to go in Trunk now?

Before it does at the very least we need:

1) An update for http://www.boost.org/development/separate_compilation.html 2) An update for the Boost.Config docs for each of these new macros. 3) A clear understanding of what BOOST_SYMBOL_FORWARD_EXPORT/IMPORT do. 4) A clear understanding of what needs re-exporting - IMO BOOST_EXCEPTION_EXPORT is somewhat misleading since as I understand the gcc docs this may need to be applied to any class that has "vague linkage" whatever that is. Also do we need to re-export std lib exceptions from our SO's? Do we have a dependency analysis to know when we need to use these (or that we don't need to)?

John.

Jürgen Hunold — Fri, 07 Aug 2009 07:25:22 GMT

John, thanks for the comment. I'm quite busy at the moment and do not think this should be added before the 1.40 release is out. I'll take a look at the docs. The question about re-export is quite tricky, as this is used without explanation in Boost.Python. I'll see what I can find. If there is more discussion necessary, we should use the mailing list. Threads are much nicer to handle ;-)) And Sun CC should be eays once the new macros are in.

arhipjan@… — Fri, 07 Aug 2009 08:50:39 GMT

Replying to johnmaddock:

Is this nearly ready to go in Trunk now?

Before it does at the very least we need:

[snip] Also do we need to re-export std lib exceptions from our SO's? Do we have a dependency analysis to know when we need to use these (or that we don't need to)?

John.

JFYI, stdcxx library (at least of version 4.1.1 and later)
already have default visibility for std::exception, std::bad_exception, i.e:

//exception header
#pragma GCC visibility push(default)
namespace std {
   class exception {/*...*/};
   class bad_exception {/*...*/};
//...

Also logic_error, runtime_error don't cause abnormal program termination
since they have key functions
(i.e. at least one non-inline virtual function).

anonymous — Fri, 07 Aug 2009 11:04:16 GMT

I forgot one other requirement: we should maybe try and put together a small test case to check that this all works.

Good to hear that libstdc++ already does the necessary work, does this mean that exceptions that inherit from std::runtime_error (as I think all Boost exceptions do?) are automatically visable and don't need re-exporting on account of their virtual functions?

Oops, one other thing (sorry!), how if at all is Boost.Exception effected by this - especially as it's header only?

Cheers, John.

anonymous — Mon, 12 Oct 2009 16:59:06 GMT

Boost.Exception should be fixed as well.

Let me explain: If I make a DSO, say a.so, which throws an exception, say my_exception, which is derived from std::exception and boost::exception, and use the GCC -fvisibility=hidden flag in building the a.so, boost::exception typeinfo is not visible to the application using the a.so, since it will be looked for inside the DSO where it's hidden. As a consequence, for example, if I try to catch a my_exception thrown from the a.so in the application side as a reference to boost::exception, it will pass right through and bad things will happen. Hence IMO boost::exception should always use default visibility with GCC similar to std::exception. In 1.40 it does not.

Another issue with Boost.Exception is the BOOST_THROW_EXCEPTION macro since it seems to throw an instance of boost::exception_detail::clone_impl<my_exception>. Since it is a template, there is an easy, non-intrusive workaround: I can just declare the specialization in my own header file with default visibility attribute. Unfortunately this can not be done for boost::exception.

All in all, IMO boost::exception should always use default visibility. Setting it in boost/exception/exception.hpp at least fixed my problems with visibility and boost exceptions.

cc set

Wed, 05 May 2010 15:30:52 GMT

cc braden@… added

John Maddock — Thu, 22 Jul 2010 09:57:12 GMT

Can this issue be closed now, or are there still bits missing from Trunk?

Jürgen Hunold — Thu, 21 Jul 2011 16:14:47 GMT

Lots of bits missing from trunk. I've patches for all non-header libraries and try to get them in now. I try to get the okay from each author/maintainer but the quickest solution would be to commit them in one go.

Jürgen Hunold — Fri, 22 Jul 2011 12:08:06 GMT

(In [73299]) Enable visibility support. Refs #2114.

Jürgen Hunold — Fri, 22 Jul 2011 14:15:48 GMT

(In [73301]) Enable visibility support. Refs #2114.

Jürgen Hunold — Sat, 23 Jul 2011 09:24:38 GMT

(In [73308]) Enable visibility support. Refs #2114.

Jürgen Hunold — Tue, 26 Jul 2011 17:40:26 GMT

(In [73381]) Merge 73299,73301,73308 from ^/trunk

r73299 | jhunold | 2011-07-22 14:08:03 +0200 (Fr, 22 Jul 2011) | 2 lines

Enable visibility support. Refs #2114.

r73301 | jhunold | 2011-07-22 16:15:45 +0200 (Fr, 22 Jul 2011) | 2 lines

Enable visibility support. Refs #2114.

r73308 | jhunold | 2011-07-23 11:24:35 +0200 (Sa, 23 Jul 2011) | 2 lines

Enable visibility support. Refs #2114.

Jürgen Hunold — Wed, 27 Jul 2011 12:16:18 GMT

(In [73400]) Enable visibility support. Refs #2114.

Jürgen Hunold — Sat, 30 Jul 2011 10:45:34 GMT

(In [73438]) Merge 73400 from ^/trunk

r73400 | jhunold | 2011-07-27 14:16:16 +0200 (Mi, 27 Jul 2011) | 1 line

Enable visibility support. Refs #2114.

viboes — Sun, 04 Dec 2011 09:40:25 GMT

See also #2309 Lack of g++ symbol visibility support in Boost.Thread

viboes — Wed, 16 Jan 2013 23:25:13 GMT

Could this ticket be closed?

status changed; resolution set

John Maddock — Tue, 31 Jul 2018 18:27:36 GMT

status new → closed
resolution → obsolete