hello-cpp-client cannot build because of hidden symbols

[PunChaFeng]

Is this a support request? No.

Describe the bug Building hello-cpp-client with the shared C++ client library results in linking errors (Undefined symbols). I think it is because all the C++ symbols are hidden.

To reproduce

• Change cmake options: BUILD_TESTING=OFF; LD_BUILD_SHARED_LIBS=ON

• Build the project, hello-cpp-client and fails.

  Expected behavior The project should be built correctly.

  Logs

  ====================[ Build | hello-cpp-client | Debug ]========================
  cmake" --build cmake-build-debug --target hello-cpp-client -j 8
  [0/2] Re-checking globbed directories...
  [103/103] Linking CXX executable examples/hello-cpp-client/hello-cpp-client
  FAILED: examples/hello-cpp-client/hello-cpp-client 
  : && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -g -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names  examples/hello-cpp-client/CMakeFiles/hello-cpp-client.dir/main.cpp.o -o examples/hello-cpp-client/hello-cpp-client  -Wl,-rpath,/Users/fengx/Works/cpp-sdks/cmake-build-debug/libs/client-sdk/src  libs/client-sdk/src/liblaunchdarkly-cpp-client.dylib  /opt/homebrew/lib/libboost_system-mt.dylib  /opt/homebrew/lib/libboost_date_time-mt.dylib  -framework CoreFoundation  -framework Security  /opt/homebrew/lib/libboost_system-mt.dylib  /opt/homebrew/lib/libboost_filesystem-mt.dylib  /opt/homebrew/lib/libboost_atomic-mt.dylib  /opt/homebrew/lib/libboost_date_time-mt.dylib  /opt/homebrew/lib/libssl.a  /opt/homebrew/lib/libcrypto.a  /opt/homebrew/lib/libboost_url-mt.dylib  /opt/homebrew/lib/libboost_json-mt.dylib  /opt/homebrew/lib/libboost_container-mt.dylib && :
  Undefined symbols for architecture arm64:
  "launchdarkly::client_side::Client::StartAsync()", referenced from:
    _main in main.cpp.o
  "launchdarkly::client_side::Client::BoolVariation(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, bool)", referenced from:
    _main in main.cpp.o
  "launchdarkly::client_side::Client::Client(launchdarkly::config::Config<launchdarkly::config::shared::ClientSDK>, launchdarkly::Context)", referenced from:
    _main in main.cpp.o
  "launchdarkly::ContextBuilder::Kind(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>)", referenced from:
    _main in main.cpp.o
  "launchdarkly::AttributesBuilder<launchdarkly::ContextBuilder, launchdarkly::Context>::Name(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>)", referenced from:
    _main in main.cpp.o
  "launchdarkly::config::shared::builders::ConfigBuilder<launchdarkly::config::shared::ClientSDK>::ConfigBuilder(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>)", referenced from:
    _main in main.cpp.o
  "launchdarkly::operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char>>&, launchdarkly::Error const&)", referenced from:
    _main in main.cpp.o
  "launchdarkly::ContextBuilder::Build() const", referenced from:
    launchdarkly::AttributesBuilder<launchdarkly::ContextBuilder, launchdarkly::Context>::Build() const in main.cpp.o
  "launchdarkly::config::shared::builders::ConfigBuilder<launchdarkly::config::shared::ClientSDK>::Build() const", referenced from:
    _main in main.cpp.o
  "vtable for launchdarkly::client_side::Client", referenced from:
    launchdarkly::client_side::Client::~Client() in main.cpp.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
  ld: symbol(s) not found for architecture arm64
  clang: error: linker command failed with exit code 1 (use -v to see invocation)
  ninja: build stopped: subcommand failed.

  SDK version commit: 857dd28

  Language version, developer tools C++17, CLion 2023.1.5, cmake version 3.27.6, boost 1.85.0

  OS/platform Apple M1 Pro, MacOS 14.5 (23F79)

  Additional context Removing set(CMAKE_CXX_VISIBILITY_PRESET hidden) can resolve the issue. Why do we hide all the C++ symbols by default?

[cwaldren-ld]

Hi @PunChaFeng , this is intentional.

We don't officially support consuming the C++ SDK as a shared library because we can't guarantee the symbols + ABI will remain stable. Specifically, if our release process causes an ABI change, we don't want to break any users who are consuming the built libraries.

In contrast, we do support using the C bindings in shared library.

But, I think it is fair that we could add a CMake option to enable this for people who can guarantee that the same build system is used for the shared libraries and their application.

Is that true for your use-case?

[PunChaFeng]

@cwaldren-ld Thank you for your detailed explanation. Your insights about the C++ SDK and the C bindings have helped me understand your intentions. I appreciate your suggestion about the CMake option, and yes, it would work for my use case.

[cwaldren-ld]

Ok, I cannot promise any timeline but your request has been noted.

I will notify you if this is released.

Filed internally as 246572.

[puncha]

@cwaldren-ld Thank you. I created a PR to address this issue. Could you please review it?