Re: [boost] Questions regarding new visibility stuff

Subject: Re: [boost] Questions regarding new visibility stuff
From: John Maddock (boost.regex_at_[hidden])
Date: 2010-07-12 04:49:50

>I found the page with the updated config documentation on the trunk.
>
> a) What happens if the library is being compiled as a static library?
> The documentation says that BOOST_SYMBOL_EXPORT is
> always defined.  So can I assume that if a static library is being
> built then it's defined a empty?

Nope, BOOST_SYMBOL_EXPORT is the equivalent to the 
__declspec(dllexport/import) that you;re using now.

> The serialization library now contains things like
> #ifdef BOOST_HAS_DECLSPEC // defined in config system
> Which I believe is undefined for when the library is being
> built statically.  So things currently work. What do I
> replace the #ifdef above with - if anything.   I believe that
> exporting symbols from an imported static library would
> create all sorts of interesting surprises.

The code is basically the same as before, but without the need to check for 
BOOST_HAS_DECLSPEC, for example:

// we need to import/export our code only if the user has specifically
// asked for it by defining either BOOST_ALL_DYN_LINK if they want all boost
// libraries to be dynamically linked, or BOOST_MATH_TR1_DYN_LINK
// if they want just this one to be dynamically liked:
//
#if defined(BOOST_ALL_DYN_LINK) || defined(BOOST_MATH_TR1_DYN_LINK)
// export if this is our own source, otherwise import:
#ifdef BOOST_MATH_TR1_SOURCE
# define BOOST_MATH_TR1_DECL BOOST_SYMBOL_EXPORT
#else
# define BOOST_MATH_TR1_DECL BOOST_SYMBOL_IMPORT
#endif  // BOOST_MATH_TR1_SOURCE
#else
#  define BOOST_MATH_TR1_DECL
#endif  // DYN_LINK

> b) the serialization library contains
>
> ...
> #if defined(__BORLANDC__)
> #define BOOST_ARCHIVE_DECL(T) T __export
> #define BOOST_ARCHIVE_OR_WARCHIVE_DECL(T) T __export
> #else
> #define BOOST_ARCHIVE_DECL(T) __declspec(dllexport) T
> #define BOOST_ARCHIVE_OR_WARCHIVE_DECL(T) __declspec(dllexport) T
> #endif
>
> This addresses the fact that with borland, the placement of the __export
> and typename differs in sequence from the rest.  I haven't tested borland
> in a long time and it's broken for the serialization library anyway (and
> no one has complained) so I suppose you can just ignore this - but
> I'd thought I'd mention it.

Hmm, I *think* that any reasonably recent Borland/Codegear version should 
support the __declspec syntax.

> c) When will these new macros get checked into the release branch?

They should be there now.

> d) It turns out that I've had to deal with this a lot more than anyone
> would want to.  In my case, I've divided the code into two separate
> libraries - serialization.dll and wserialization.dll.  The second includes
> only those parts which depend on wide character types.  The motiviation
> is that one only needs the part he is really using.  Problems come up
> as wserialization import symbols from serialization so the import/export
> issue get's sort of complicated.  User programs have the same issue
> as I've found in making dll/plugin tests.  I don't have a real point here,
> just noting my experiences with this issue.

Robert, two libraries aren't any harder than one library - but you must 
treat them as two separate libraries - so you'll need separate macros for 
each to decorate your code with, and separate macros to indicate which one 
is being built.  That'll ensure that when you build the wide character 
library (for example) that any code from the narrow character / common 
library it depends on gets marked as imported not exported.  The situation 
you have is the same as the filesystem and system libraries I believe?

HTH, John.