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.