Patch for export symbols from shared library

[arhip]

Attached patch provides macroses:
BOOST_DSO_EXPORT
BOOST_DSO_IMPORT
etc...
They specify what symbol to export/import when building/using
shared library. Only compilers msvc, borland and gcc affected.
For the others toolsets macroses do nothing.
Also, all the libraries updated
(mainly config.hpp and Jamfile.v2 files) in order to use
export/import functionality.
Boost.Serialization and Boost.Python wasn't touched because
Serialization had a lot of linker errors when running
test cases and
Boost.Python had it's own gcc export/import stuff.

[anonymous]

patch file

[Jürgen Hunold]

One example of missing visibility support is #2309.

[anonymous]

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

[anonymous]

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

[arhipjan@…]

patch updated: boost-build part

[anonymous]

patch updated: boost part

[Jürgen Hunold]

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]

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]

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@…]

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]

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.

[Jürgen Hunold]

Fixed patch using existing headers

[bschaeling]

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.

[John Maddock]

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]

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@…]

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]

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]

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.

[John Maddock]

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

[Jürgen Hunold]

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]

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

[Jürgen Hunold]

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

[Jürgen Hunold]

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

[Jürgen Hunold]

(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]

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

[Jürgen Hunold]

(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]

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

[viboes]

Could this ticket be closed?