Export C++ symbols in dynamic Windows libraries

[ischoegl]

Abstract

At the moment, symbols in dynamic libraries are not exported in Windows, i.e.

> dumpbin /exports cantera_shared.dll
Microsoft (R) COFF/PE Dumper Version 14.31.31104.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file cantera_shared.dll

File Type: DLL

  Summary

        1000 .00cfg
       19000 .data
        5000 .idata
       40000 .pdata
       F9000 .rdata
        B000 .reloc
      5E3000 .text
        1000 .tls

does not list any symbols (whereas running dumpbin /LINKERMEMBER cantera_shared.lib for the static library lists an extensive list of symbols - at least for the C API?)

Motivation

Describe the need for the proposed change:

• What problem is it trying to solve? ... allow access to C++ methods in shared dynamic libraries
• Why is this a good solution? ... make shared dynamic libraries usable on Windows platforms

The ability of accessing Cantera C++ classes and functions at run-time will open additional pathways for the definition of alternative API's and uses in 3rd party applications.

Possible Solutions

Per SO answer, a platform-independent preprocessor macro

// If we are Microsoft C/C++ Compiler
#if defined(_MSC_VER)
    #if defined(DLL_EXPORT)
        #define API __declspec(dllexport)
    #else
        #define API __declspec(dllimport)
    #endif

// If we are non Windows (Export by default) or compiling to a StaticLibrary
#else
    #define API 
#endif

will properly export symbols for classes / functions that include the API decoration. Note: this is just copy-paste from SO, and thus is untested / may need tweaks. There are likely parts of the SCons build that will have to be adjusted.

References

• Split Cantera into core and toolbox libraries #97
• MATLAB Interface Discussion #102

[bryanwweber]

This seems like a fairly non-intrusive change. Are there any side effects of doing this, other than perhaps larger binaries? I don't see how SCons would affect this if the macro goes somewhere like global.h.

[ischoegl]

This seems like a fairly non-intrusive change. Are there any side effects of doing this, other than perhaps larger binaries?

Fairly non-intrusive, but tedious, as I believe the decorations need to be applied all over the place (also: I don't expect side effects). The macro should definitely go into global.h; the only reason I mentioned SCons is that I wouldn't be surprised if there were a couple of stumbling blocks hidden someplace. This always seems to be the case 😂

I'd be happy to start some tests, but will wait until after 2.6 is released and CTI/XML support etc. is removed. To me personally, this is something I'd like to see in Cantera 3.0 ...

[ischoegl]

Fwiw, the definitions above are already included in clib_defs.h but used (mostly) for the CAPI only (exception: funcWrapper.h) ...

[speth]

Here's article that I found helpful in covering some of the quirks/limitations of exporting C++ classes in a DLL: https://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL