cn-cc opened a new issue, #1399: URL: https://github.com/apache/rocketmq-clients/issues/1399
### Before Creating the Bug Report - [x] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq-clients/discussions). - [x] I have searched the [GitHub Issues](https://github.com/apache/rocketmq-clients/issues) and [GitHub Discussions](https://github.com/apache/rocketmq-clients/discussions) of this repository and believe that this is not a duplicate. - [x] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ. ### Programming Language of the Client C++ ### Runtime Platform Environment OS: Windows 11 x64 ### RocketMQ Version of the Client/Server Client Version: cpp‑5.1.1, also exists on current master branch ### Run or Compiler Version Compiler: MSVC 19.38 (Visual Studio 2022) CMake: 3.31.6, Generator: Ninja ### Describe the Bug Related closed issue #1234 described similar symptom but without full root‑cause analysis. The file `cpp/source/exports.map` is a GNU‑ld version‑script only valid for Linux GCC/Clang. MSVC link.exe completely ignores this map file, there is NO Windows‑compatible symbol‑export mechanism. No `__declspec(dllexport)` decorations are applied to public API classes inside `include/rocketmq/*.h`. When building target `rocketmq_shared` on Windows‑MSVC: 1. Build completes and outputs `rocketmq_shared.dll`. 2. The DLL exports zero symbols. 3. MSVC linker will **not generate import‑lib `rocketmq_shared.lib`**. 4. After `ninja install`, external CMake project cannot link against installed rocketmq_shared. Important facts: 1. Top‑level CMakeLists.txt contains explicit `install(TARGETS rocketmq_shared)`, which indicates the project intends to ship this shared library for downstream usage. 2. In‑tree build (`add_subdirectory`) works fine on Windows (examples compile and run), because CMake target linking does not require disk‑based import‑lib. 3. Bug only occurs in out‑of‑tree workflow: pre‑build → ninja install → consume via `find_package()`. This workflow is not covered by Windows CI. ### Steps to Reproduce 1. Clone repository with submodules. 2. Configure CMake with Ninja‑MSVC, build rocketmq_shared SHARED target. 3. Run `ninja install`. 4. Create external CMake project, call `find_package(rocketmq CONFIG REQUIRED)`. 5. Link error occurs due to missing import‑lib. ### What Did You Expect to See? Either of the two resolutions is acceptable: 1. Add Windows‑compatible symbol‑export mechanism (GenerateExportHeader + decorate public classes with export macro), so rocketmq_shared.dll exports symbols and produces import‑lib after install. OR 2. If Windows install‑mode SHARED library is not planned to be supported: - Add warning comment in CMakeLists.txt - Document this limitation in README, recommend static‑library or `add_subdirectory` workaround. ### What Did You See Instead? rocketmq_shared.dll is produced but exports nothing; no import‑lib file is generated. External project linking fails after ninja install. ### Additional Context Using `add_subdirectory()` can work around this bug, but brings drawbacks: - Rebuild the whole rocketmq‑clients every time consumer project compiles. - Internal third‑party dependencies (asio, fmt, spdlog etc.) leak into consumer project scope with version‑conflict risk. - Cannot use fixed release‑version protoc / grpc_cpp_plugin when consumer project builds in Debug configuration. Pre‑compiled install‑based workflow is valuable for Windows C++ developers. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
