Can't use C++ Client SDK functions with the prebuilt artifacts for v3.3.3

[morrism05]

Describe the bug I've downloaded the prebuilt artifacts for the windows-msvc-x64-dynamic.zip launchdarkly-cpp-client v3.3.3 from your releases page here. I am able to use the prebuilt lib and dll to build and run the example hello-c-client, but I get linker errors when I try to use it with the example hello-cpp-client. I believe the prebuilt lib and/or dll is missing the C++ interfaces.

To reproduce Steps to reproduce the behavior:

• In Visual Studio 2022 on a Windows computer, I started a new C++ 17 Windows console app.
• I copied the contents of the example hello-cpp-client into my new C++ windows console app.
• I downloaded the windows-msvc-x64-dynamic.zip for the launchdarkly-cpp-client v3.3.3 from the releases page here, extracted it, and updated the C++ "Additional Include Directories" and linker "Additional Library Directories" to have the appropriate directory paths.
• I built my C++ windows console app and got LNK2019 errors like LNK2019 unresolved external symbol "public: __cdecl launchdarkly::client_side::Client::Client(struct launchdarkly::config::Config,class launchdarkly::Context)" (??0Client@client_side@launchdarkly@@QEAA@U?$Config@UClientSDK@shared@config@launchdarkly@@@config@2@VContext@2@@Z) referenced in function main LDHelloWorld

Note that when I then tried to compile the C example hello-c-client instead with my LD credentials, I could successfully compile, link and run the example code.

Furthermore, when I use the Visual Studio 2022 command prompt to run "dumpbin /symbols launchdarkly-cpp-client.dll", I only see names like LDArrayBuilder_Add and LDClientSDK_New which appear to be the C interfaces.

Expected behavior I expect the prebuilt artifacts for the windows-msvc-x64-dynamic.zip to support building and linking against the C++ client SDK classes and functions.

SDK version 3.3.3

Language version, developer tools C++17 on Visual Studio 2022 17.8.5

OS/platform Windows 10

dumpbin_outputs.txt

[cwaldren-ld]

Hi @morrism05 , thanks for bringing up this issue (and all the detail!). If I understand correctly, you're trying to dynamically link against the C++ Client SDK.

From the README:

The shared library (so, DLL, dylib), only supports the C interface. The shared object does not require you to have Boost or OpenSSL available when linking the shared object to your project.

This is because we don't want to (can't) promise a stable ABI for our shared objects. That's why it works fine with the C interface; we hide all other symbols.

I'm sorry this was probably a time sink for you, it's probably buried too deeply in the README.

In any case, the solution is to link statically. Would that be acceptable for you?

[morrism05]

@cwaldren-ld thanks for the prompt reply! Yes, we are trying to dynamically link against the C++ Client SDK.

(In fact, we dynamically link against LaunchDarkly's 2.0.3 C++ SDK today. But our security scans say v2.0.3 using a version of curl with a security vulnerability, so we need to update.)

We might be able to use the C interface instead, but we are concerned about the Boost 1.81 requirement. Is the Boost requirement a build-time only requirement or is it a runtime requirement? Our application does not use Boost at runtime.

[cwaldren-ld]

In fact, we dynamically link against LaunchDarkly's 2.0.3 C++ SDK today.

I can't recommend continuing to use the 2.0.3 C SDK since it's deprecated - but if you were forced to, you could build it from source with a more recent version of CURL than our release process used at the time.

Is the Boost requirement a build-time only requirement or is it a runtime requirement? Our application does not use Boost at runtime.

It's a build requirement only:

The shared library (so, DLL, dylib), only supports the C interface. The shared object does not require you to have Boost or OpenSSL available when linking the shared object to your project.

[morrism05]

Thank you for the feedback! We'll probably just use the C SDK from our C++ app so that we can continue to use your prebuilt DLLs.