[cfe-dev] May libc++ support symbol versioning?

[Zhihao Yuan via cfe-dev]

On Tuesday, February 25, 2020 8:49 AM, David Chisnall via cfe-dev <cfe-dev at lists.llvm.org> wrote:

> Hi,
>
> I would be interested to know who is making that statement on behalf of
> the FreeBSD project. We made a conscious decision not to use symbol
> versioning for the FreeBSD build of libc++ when we imported it.

The thread is here; you are welcome to check it out:

https://lists.freebsd.org/pipermail/freebsd-hackers/2020-February/055669.html

>
> Symbol versioning allows you to provide versions for exported symbols.
> This is a good solution for maintaining backwards compatibility in C
> libraries, where the only things exported from a library are functions
> (or, occasionally, globals) and it is often possible to provide
> backwards-compatibility versions of functions. For example, FreeBSD
> libc provides some compat versions of stat for callers that will provide
> a smaller statbuf structure than the newer version of the API expects to
> fill.
>
> In contrast, C++ libraries export complex types and expect to inline a
> large number of the operations on them. The boundary of a C++ library
> is much more fuzzy.

Apparently, libstdc++ did it.

> Types declared in libc++ headers become part of the
> name mangling for any functions that take them as arguments. Symbol
> versioning does not help with that at all.

libc++ had never changed name
mangling regarding types, IIUC.

--
Zhihao