C++ codegen with __declspec(dllexport) #2026
Replies: 4 comments 2 replies
-
|
This is not supported, no. Even the Cap'n Proto runtime library itself lacks export declarations. Somewhat surprisingly, I don't think anyone has ever brought up the issue until now, suggesting that demand for dynamically linking capnproto on Windows is pretty low. I'd accept a PR to support it, but it's a lot of work and I don't expect to have the bandwidth to work on it myself. If you want to make a PR, please target the |
Beta Was this translation helpful? Give feedback.
-
|
I had a need to add Windows export declarations for capnproto-c (not C++) a while back. If needed, you may want to start with the CMake bits at https://gitlab.com/dkml/ext/c-capnproto/-/blob/1089ab8441b10765579d17ca519278a5c31dea0c/CMakeLists.txt#L55-136 and then work your way into the code. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the suggestions! However, in the end, we went with the cheapest solution and hacked our build system to do a regex replace of |
Beta Was this translation helpful? Give feedback.
-
I'm glad I saw this discussion thread. Cap'n Proto is at the top of my list of targets for a (very long overdue) migration away from Protobuf 2. We need the ability to use dynamic linking on Windows however, so that means our migration cost would also need to include the cost of annotating the runtime library for symbol visibility before we could ever start on our own code. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW this came up yesterday: #2456 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
You have two options for symbol visibility:
Controlling symbol visibility is nice to do even on non-Windows systems where it isn't strictly required which is why I always go the macro route. Additionally macros are easier to keep synchronized than a separate .def file. However writing those macros is tricky. CMake has built-in support for writing the macros, however recently it has recently come out that this approach isn't quite sufficient (however the author of that article ignores the case of a static library build, a situation which CMake's macros handle and his macros don't). |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Currently, generated C++ source code from capnp schema files use
CAPNP_DECLARE_SCHEMAmacro, which expands toextern <schema global vars>. As a result, I am unable to have users of my shared library link to these schema variables since they are not exported.Is there a way for me to control the codegen to generate
__declspec(dllexport)in place ofextern? Better yet, would it be possible for it to generateMY_APImacro in place ofexernso thatMY_APIcan generate platform specific export attributes?Beta Was this translation helpful? Give feedback.
All reactions