Add pluggable shared libraries releases?

[rnburn]

I'm working on making self-contained, pluggable, shared libraries releases for tracers where users can download a binary instead of building from source. The steps to produce such a library involve

• Linking in all dependencies statically
• Using the -static-libstdc++ and -static-libgcc flags so that the standard C++ library isn't required
• Applying an export map to avoid dependency clashes and to only expose the minimum required symbols

I recently added this to https://github.com/rnburn/zipkin-cpp-opentracing for amd64-linux. This script shows how the library can be build. You can also use https://github.com/tcnksm/ghr to automatically build and attach these libraries to github releases.

Is this something you'd be interested in adding for Jaeger? An additional benefit is that this will produce a library in a form that's usable by Envoy's dynamic tracing code; so we could add an example to https://github.com/envoyproxy/envoy/tree/master/examples, and envoy users would be able to trace with Jaeger natively instead of using Zipkin with Jaeger.

[isaachier]

I love the idea of using https://github.com/tcnksm/ghr. Will get around to it myself when possible unless someone beats me to it.

[isaachier]

Figuring out the dependencies is going to be pretty tedious for jaeger-client-cpp. I was hoping to get a C client out soon enough. That would make linking a lot simpler and the plugin much smaller. Is there an ETA for this feature you had in mind?

[rnburn]

It should take too long. I can provide a PR with a script to build the plugin.

The dependencies should be all linked in and an export map will be used so that they won't clash if the user happens to also be linking to them, so the plugin itself will be completely self-contained. You can see how it works with the zipkin plugin I made: https://github.com/rnburn/zipkin-cpp-opentracing/releases

You can certainly evolve and have other releases produce a different shared library, but I would go forward with what you have.

[isaachier]

OK let me give it a shot now. Thanks for the offer. I'll let you know if I get stuck.

[isaachier]

OK so here's the breakdown. Seeing as I use Hunter, and I turn on -fPIC using CMake's option here, that means all of my dependencies are built with the same CMake option (Hunter guarantees that except for maybe OpenSSL, which uses autotools). In that case, do I need to bother building opentracing-cpp like you do in the Zipkin example?

About the version map, could I possibly use something less compiler specific like https://cmake.org/cmake/help/v3.1/module/GenerateExportHeader.html?

Which brings me to the next question, how portable is this plugin supposed to be? It seems to only target x86-64 (granted that is pretty much ubiquitous).

[rnburn]

You already have PIC turned on for even your static libraries (https://github.com/jaegertracing/jaeger-client-cpp/blob/master/cmake/toolchain.cmake#L4), so you shouldn't need to do anything with that.

There are some other ways of producing the same effects as an export map (e.g. default everything to have hidden visibility and explicitly mark the functions you want to export); but I think an export map is the least intrusive way to get started.

I'm only targeting linux-amd64 initially. But I mark the architecture in the release binary, so you could certainly add and mark plugins for other platforms if there's demand for them. The expectation is the plugins would be managed the same way as the binary releases in other projects. (See for example a protobuf release where there's attachments for each platform https://github.com/google/protobuf/releases/tag/v3.5.1)

[isaachier]

OK great just making sure. I don't mind the map seeing the single usage here as opposed to changing the code, especially the opentracing-cpp global symbol. In terms of the release strategy, that makes the most sense. Most people are deploying to Linux amd64 as it is.

[rnburn]

BTW - the code in https://github.com/rnburn/cpp-client/tree/plugin/plugin has a script that will build a plugin into /tmp/jaeger-docker-build or wherever you set JAEGER_DOCKER_BUILD_DIR. I wrote it before I knew you were going to work on it. Feel free to copy any part of it if you like.

I also have https://github.com/rnburn/ot-chat-example/tree/master/jaeger which has a docker-compose example with the plugin that I've been testing with.

[rnburn]

@isaachier - I don't think this is quite done yet. Could you attach the shared library built to Jaeger's release?

[isaachier]

@rnburn I don't have a release with this yet but ran locally and produced this from current master (359979c). Had to append .txt so GitHub would allow upload here.
libjaegertracing_plugin.so.txt

[rnburn]

Could you attach as an asset to Release 0.3.0 like it's done here? I think that's where people would expect to find it.

[yurishkuro]

@isaachier cf. jaegertracing/jaeger#766

[rnburn]

Even if the automated build isn't done yet, could you attach to the release manually? It would let me go forward with putting in the documentation to envoy.

[isaachier]

I would rather add a new release than attempt backporting the changes on top of an older one.

[isaachier]

But ya let me start on the release now to unblock you.

[isaachier]

See release 0.4.0.

[Sund3]

Hey, why did you stop publishing the portable binary? I need it for docker images