Weak symbols without symbol version

[Philipp Wähnert]

> Yes, as long as the version of libstdc++ the binary uses at runtime is
> not older than the one used to compile against (but that's always
> required, independently of your question)

That's a bit unfortunate and differs from the behavior of the glibc. If I
restrict myself to a subset of symbols and symbol versions from a glibc version
prior to the currently used one, I got a valid binary for systems using this
older version.

I'm asking this whole thing, because we're maintaining a library written in C++
with a C API. We're obliged to guarantee a huge backwards compatibility. The
oldest system is CentOS 6 which still uses GCC 4.4. Currently we're compiling
against LSB 4.1. Be we're really keen on using all this new and shiny C++11
features and it's my task to do the research.

Please let me present you my previous findings and I would be glad to hear some
opinions or perhaps some new perspectives from you!

Since it's a library used by other application we can't simply bundle it up
with a suitable libstdc++ and be done with it. The applications using our
library would be forced to use at most the version of our libstdc++. This seams
a bit harsh to me.

My next attempt was to link the libstdc++ statically into our library. But this
approach has its own downsides. First, our library in fact consists of a core
library and many plugin libraries. Linking statically, we would have to link
each library with the libstdc++ causing a significant increase in the overall
binary size. And secondly, we would have to be very careful by passing C++
objects across the library boundaries. Probably there would be no exception
throwing and catching and dynamic casting across those boundaries.

The third attempt was to link our library dynamically to an own version of
libstdc++, say libspecialstdc++. If I could tag all its symbols with a special
version, e.g. SPECIAL_GLIBCXX_x.y.z, the dynamic linker could bind all those
identical named symbols to the correct libraries. Our library uses
SPECIAL_GLIBCXX_x.y.z and the application uses the plain GLIBCXX_x.y.z
versions. Until I got a glimpse of those weak symbols stemming from templates
like this mentioned operator +(), I thought my evil plan would actually
succeed. Now I'm back to start.

Do you have a completely different approach up in you sleeve or further
objections to my approaches?