dd-opentracing-cpp win x64 opentracing::DynamicallyLoadTracingLibrary always ends up in opentracing/dynamic_load_unsupported.cpp

[buzz3791]

I’m using the code C++ tracing example on Windows x64 [1]. At runtime, the opentracing::DynamicallyLoadTracingLibrary call [2] always ends up in the opentracing/src/dynamic_load_unsupported.cpp version of DynamicallyLoadTracingLibrary [3] rather than the correct Windows version opentracing-cpp/src/dynamic_load_windows.cpp [4].

What build dd-opentracing-cpp build changes do I need to make to correct this defective behavior in the Windows build?

1 - https://github.com/DataDog/dd-opentracing-cpp/blob/master/examples/cpp-tracing/dynamic-loading/tracer_example.cpp 2 - https://github.com/DataDog/dd-opentracing-cpp/blob/3ae0d0b1c1b5e77eac76bd588cb376d59234642d/examples/cpp-tracing/dynamic-loading/tracer_example.cpp#L9C39-L9C39 3 - https://github.com/opentracing/opentracing-cpp/blob/06b57f48ded1fa3bdd3d4346f6ef29e40e08eaf5/src/dynamic_load_unsupported.cpp#L5 4 - https://github.com/opentracing/opentracing-cpp/blob/06b57f48ded1fa3bdd3d4346f6ef29e40e08eaf5/src/dynamic_load_windows.cpp#L34

The screenshot below shows the call stack in WinDbg…

[dgoffredo]

Line 1114 in your screenshot caught my teammate's eye. Is opentracing.dll the Datadog tracing plugin library, or is it some library coming from opentracing-cpp? If it's the Datadog plugin, then we might expect "dd" to appear somewhere in the name of the file.

[buzz3791]

If I try to change to dd_opentracing.dll, I get the following runtime errors:

Entry Point Not Found 
The procedure entry point 
?inject@Tracer@v3@opentracing@@UEBA?AV?$expected@XVerror_code@std@@@23@AE8VSpanContext@23@AE8VCustomCarrierWriter@23@@Z
could not be located in the dynamic link library

Entry Point Not Found 
The procedure entry point
?propagation_error_category@v3@opentracing@@YAAE8Verror_category@std@@XZ
could not be located in the dynamic link library

I had resort to using opentracing.dll instead of dd_opentracing.dll because of #268 .

[dgoffredo]

I'm assuming that opentracing.dll is the library built from the opentracing-cpp project and that dd_opentracing.dll is the library built from this project (dd-opentracing-cpp).

If so, then the plugin loader provided by opentracing::DynamicallyLoadTracingLibrary must be given dd_opentracing.dll. It does not make any sense to give it opentracing.dll.

The linkage error involving CustomCarrierWriter rings a bell for me. I'll look through my notes to see what I've done about it before (but it wasn't on Windows).

Next week my teammate and I will be focusing on our bug report backlog. Perhaps I will be able to revisit Windows then, given your helpful notes. Not sure, but I will update again sometime next week.

[dgoffredo]

I can't find anything in my notes about ?inject@Tracer@v3@opentracing@@UEBA?AV?$expected@XVerror_code@std@@@23@AE8VSpanContext@23@AE8VCustomCarrierWriter@23@@Z, which refers to the inline member function defined here.

I recall trying to get things to build in some environment (again, not Windows), and the linker issued a similar complaint.

[dgoffredo]

Now I remember.

I added an implementation of opentracing::Tracer to Envoy as part of a unit test.

I thought that there should be no need for me to define that function, because the base class provides an implementation. Yet some part of Envoy's build complained.

Our implementation of opentracing::Tracer in dd-opentracing-cpp does not provide a definition for that function. Perhaps adding the following to class Tracer in dd-opentracing-cpp/src/tracer.h would fix it:

  ot::expected<void>
  Inject(const ot::SpanContext& sc,
         const ot::CustomCarrierWriter& writer) const override {
    return ot::Tracer::Inject(sc, writer);
  }

[buzz3791]

@dgoffredo Thanks for your replies. Note in this ticket I mentioned I had to resort to linking opentracing.lib rather than dd_opentracing.lib because of #268. In my comment above I originally mentioned the wrong issue number. I corrected it just now.

If I wasn't trying to work around #268, I would have only used dd_* link lib and DLL.

[dgoffredo]

The only option is to find a workaround for whatever build/link issues you're encountering with dd_opentracing.dll. If dd_opentracing.dll and opentracing.dll refer to what I assumed they do above, then the plugin loader must be given dd_opentracing.dll. dd_opentracing.dll is a plugin, while opentracing.dll is not.

[buzz3791]

OK, I understand I can only use dd_opentracing.lib and dd_opentracing.dll. I'll focus on trying to resolve #268 first then #267 may not be an issue.

[buzz3791]

@dgoffredo I resolved the issue. The root cause is a defect in the configuration of dd-opentracing-cpp’s vcpkg for the opentracing dependency [1]. I’m not sure the correct way to “automate” the necessary fix (maybe via vcpkg custom triplet or overlay triplet) but essentially the dependency’s portfile.cmake needs to have vcpkg\ports\opentracing\portfile.cmake -DBUILD_DYNAMIC_LOADING=ON the default Windows build instructions result in incorrectly defaulting the opentracing BUILD_DYNAMIC_LOADING build macro to OFF rather ON.

After switching this value to ON. I then executed these vcpkg commands: vcpkg remove opentracing:x64-windows vcpkg install opentracing:x64-windows This built vcpkg\packages\opentracing_x64-windows\lib\opentracing.lib and bin\opentracing.dll that uses the correct dynamic_load_windows.cpp.

I built my EXE linking against opentracing.lib and dd_opentracing.lib. My EXE is loading dd_opentracing.dll. Everything is working now.

1 - https://github.com/DataDog/dd-opentracing-cpp/blob/3ae0d0b1c1b5e77eac76bd588cb376d59234642d/vcpkg.json#L10

[dgoffredo]

Thanks for having the patience to find a fix and to describe it here!

I'll leave this issue open so that we can integrate your findings into our build when we revisit (revise) Windows support.