[C++-sig] win32: BOOST_PYTHON_MODULE always exports DLL symbols

David Abrahams dave at boost-consulting.com
Fri Jan 3 15:51:04 CET 2003


"Nicolas Lelong" <n_lelong at hotmail.com> writes:

> The 'problem' I have is with BOOST_PYTHON_MODULE_INIT in 'module_init.hpp'
> that always define (for win32) the init##name function as [cut & paste] :
>
> # if defined(_WIN32) || defined(__CYGWIN__)
> # define BOOST_PYTHON_MODULE_INIT(name) \
> void init_module_##name(); \
> extern "C" __declspec(dllexport) void init##name() \
> [...]

Aha! Sorry for not understanding this earlier.

> I can see no way for BOOST_PYTHON_STATIC_LIB to control the 'init##name'
> declaration.
> In fact, I think that this definition could be changed to :
>
> # if defined(_WIN32) || defined(__CYGWIN__)
> # define BOOST_PYTHON_MODULE_INIT(name) \
> void init_module_##name(); \
> extern "C" BOOST_PYTHON_DECL void init##name() \
> [...]

Yeah, I don't think that's the right fix, because it will make your
init##name() function into an IMported function when you link against
the Boost.Python DLL.

> But in this case, having BPL as a static lib (with
> BOOST_PYTHON_STATIC_LIB defined) will prevent from being able to
> create DLL modules. In my local modifications, I started having a
> symbol BOOST_PYTHON_EXTEND_EMBEDDED that allowed me to explicitly
> tune the BPL code for my specific purpose of extending an embedded
> python (such as disabling all dll exports, mainly) - but maybe i
> missed something. Any thoughts?

Wouldn't it be enough to have a symbol which determines whether module
init functions are exported or not, in addition to having
BOOST_PYTHON_STATIC_LIB?

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution





More information about the Cplusplus-sig mailing list