Subject: [boost] Questions regarding new visibility stuff
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-07-11 13:58:15
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?
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.
b) the serialization library contains
#define BOOST_ARCHIVE_DECL(T) T __export
#define BOOST_ARCHIVE_OR_WARCHIVE_DECL(T) T __export
#define BOOST_ARCHIVE_DECL(T) __declspec(dllexport) T
#define BOOST_ARCHIVE_OR_WARCHIVE_DECL(T) __declspec(dllexport) T
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.
c) When will these new macros get checked into the release branch?
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk