Does dynamic loading work for C library?

[tamalsaha]

ref: https://medium.com/opentracing/opentracing-plugins-for-c-7ccea7a6d21a

[rnburn]

I expect we'd want to make some tweaks to the dynamic loading API similar to opentracing/opentracing-cpp#91.

There also aren't any C tracers completed to load against.

But I think a C++-to-C bridge that allows you to use the existing C++ tracers with the C dynamic loading API would be a very useful project if anyone wants to work on it.

[Oberon00]

This C++-to-C bridge would be even more useful if paired with a C-to-C++ bridge: This way one could implement a tracer in C++ or C and expose a C interface and it could be used by both opentracing-c and opentracing-c++ without having to worry about C++-specific ABI problems

With a C API, one could probably provide a precompiled tracer implementation binary for a platform like Linux-x86_64-opentracing-vX instead of e.g. Linux-x86_64-envoy-vX, where envoy means that it is compiled with all the tool/compiler options and versions that make it work with that particular application and version thereof (I believe this is the status quo).

[rnburn]

With a C API, one could probably provide a precompiled tracer implementation binary for a platform like Linux-x86_64-opentracing-vX instead of e.g. Linux-x86_64-envoy-vX, where envoy means that it is compiled with all the tool/compiler options and versions that make it work with that particular application and version thereof (I believe this is the status quo).

No, that's not the status quo. Tracers already provide precompiled binaries targeted for platforms, not specific applications. And I don't know that C++-ABI incompatibilities pose that much of a problem: Nearly all linux distributions are based off of libstdc++ which has had a stable ABI since supporting C++-11.

[Oberon00]

Well, the C++ ABI is not as stable as the C ABI, for example see the -fabi-version option for g++. Although it seems that recently the changes affect only edge cases so the opentracing-cpp ABI may actually stay compatible over g++ ABI versions.

Regarding the standard library ABI, I thought it was much more unstable, but after reading https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html more closely, it seems that the library stays in fact quite compatible. I'm somewhat concerned that the section "Multiple ABI Testing" there tests a C program linking against C++ shared libraries compiled with different g++ versions, so the C++ libs in this test have to expose C-only interfaces. But it seems that section is quite outdated.

The above considers only Linux. On Windows the situations is worse, as usually each new MSVC release breaks the ABI (though Microsoft becomes better: The most recent two (VS 2015 14, 2017 15) and the upcoming version of MSVC (2019? 16) will have binary compatible C++ ABIs, including the standard library -- but this is a first, and an ABI breaking release will definitely happen again in the future as bugs which cannot be fixed without breaking the ABI pile up). Of course, a C-only API alone also won't cut it on Windows. You also must avoid any standard library types, errno and locale dependencies, etc. in interfaces (cf. https://stevedower.id.au/blog/building-for-python-3-5/), but the opentracing-c API looks good in that regard 👍

[pgroke-dt]

@rnburn The C++ ABI being kept more-or-less stable is something that was never planned. And it restricts the library maintainers greatly. It basically freezes the fundamental design and layout of all standard library types plus all meta data like vtables, RTTI info etc.

IMO trying to keep a stable ABI across mayor compiler/standard-library releases is a mistake. It's still being done, probably because of pressure from the community to not break a lot of projects. Projects that made the mistake of using C++ in interfaces that require a stable ABI. However I think sooner or later the library maintainers will decide to break compatibility, to allow for improved implementations of stuff like the standard containers, strings, streams etc.

Therefor I would argue that any interface that requires a stable ABI should not use C++. And I would further argue that most if not all plugin/extension/module interfaces should be considered as requiring a stable ABI. Simply because there will always be plugins/extensions/modules that are a) not built+distributed with the application itself and b) also not available as a package for most/all Linux/BSD/... distributions.

[rnburn]

@rnburn The C++ ABI being kept more-or-less stable is something that was never planned.

I don't know what you mean by "never planned". The opentracing-cpp API maintains an ABI version. While it tries not to break it often, it does allow for ABI breaking releases and has a versioning mechanism to detect incompatible ABIs.

And it restricts the library maintainers greatly.

It restricts the maintainers of the OT-C++ API, but that shouldn't change frequently anyways and I wouldn't say it imposes many restrictions on maintainers of the tracer implementations.

IMO trying to keep a stable ABI across mayor compiler/standard-library releases is a mistake.

That was never the plan and I'm not aware of anyone trying to do that. It does provide for ABI stability across stable standard C++ library versions. And in practice, the most common standard c++ library on linux (libstdc++) has had a stable ABI since supporting c++11.

That said - I'm not opposed to a C API so if you see demand for it, feel free to propose one.

[pgroke-dt]

@rnburn By "never planned" I meant it was not planned when designing the C++ language. Also I was talking about restricting the C++ standard library maintainers, not the maintainers of the OT-C++ API.

That said - I'm not opposed to a C API so if you see demand for it, feel free to propose one.

Having support for OT-C++ now, one obvious choice would be the OT-C API.