WenTao Ou
WenTao Ou
I have no simular environment to run this case, could you please try to use valgrind to run this test and we can analysis which object is freed twice. >...
To build otel-cpp as a shared library, gRPC must also be built as shared libraries to avoid symbol conflicts in multiple runtime targets, which could lead to crashes.
> @owent, if this is the only supported method then I propose the CMake build should be changed to fail here: > > https://github.com/open-telemetry/opentelemetry-cpp/blob/main/cmake/opentelemetry-proto.cmake#L350-L353 > > If BUILD_SHARED_LIBS is ON...
Good point, do we need a new class to describe `any` and a new `variant` which contains `map`? It may changes the ABI. @open-telemetry/cpp-approvers
Could you please retry with `-DWITH_ABSEIL=ON` ?
`find_package` will produce warning when it's called recursively. Shoud we just add warnings to let users call `find_package` for dependencies before otel-cpp?
> > `find_package` will produce warning when it's called recursively. > > What warnings? Calling `find_package` or `find_dependency` in config files is standard practice. Sorry, calling `find_package` recursively with `FindXXX.cmake`...
According to we can use callback or a event to notify users the result of exporting. It may changes ABI, should we discuss how to implement it? @open-telemetry/cpp-approvers @open-telemetry/cpp-maintainers
Not sure if it's related to CPU cache line. Should we try to declare got_response_ as `atomic` to see if it will happen again?
Could you please check whether `HAVE_ABSEIL` is in `INTERFACE_COMPILE_DEFINITIONS` of `opentelemetry-cpp::api`?(located in `${opentelemetry-cpp_DIR}/opentelemetry-cpp-target.cmake`) It seems otel-cpp's headers are included without `HAVE_ABSEIL`, this macro should be defined automaticly by cmake when...