Add __cxa_deleted_virtual to libcxxrt's version map

[dim]

Summary

See https://bugs.freebsd.org/200863 for details. The patch there adds
it to the first part of libcxxrt's version map, under CXXABI_1.3, but
when I checked upstream libsupc++, they put this symbol under
CXXABI_1.3.6. So we should probably also put it under this version.

That said, I'm not entirely sure about the dependencies, e.g. whether
CXXABI_1.3.6 shoudl be depending on CXXABI_1.3.1 or something else.

Alternatively, we could put these under the CXXRT_1.0 part, since some
of the functions there (e.g cxa_allocate_dependent_exception and
cxa_free_dependent_exception) are in CXXABI_1.3.6 in libsupc++. So we
are not compatible with libsupc++ on that front anyway.

[emaste]

lib/libcxxrt/Version.map

293 ↗

(On Diff #6272)

should this be 1.3.6 now

[dim]

lib/libcxxrt/Version.map

293 ↗

(On Diff #6272)

Yes, that is very likely.

[dim]

Make CXXRT_1.0 dependent on CXXABI_1.3.6 instead.

[emaste]

I think this is fine, but would like to have @theraven comment as he can probably provide a definitive answer.

[theraven]

Phabricator doesn't seem to want to show me the diff, but it sounds sensible. Have we shipped a version in 9/10 that uses this symbol? If so then we should check that old binaries still run with the new .so, otherwise I think it's fine.

Generally, I'd been following the policy that symbols that were not present in libsupc++ in 8.x go in the CXXRT version namespace to avoid conflicts, but I don't see a problem with putting them in the other namespace as well. I think (hope?) that libstdc++ in ports is linking libcxxrt instead of libsupc++, so it shouldn't matter what we're doing, as long as we're self-consistent.

[dim]

In D2850#55153, @theraven wrote:

Phabricator doesn't seem to want to show me the diff, but it sounds sensible. Have we shipped a version in 9/10 that uses this symbol?

It depends on what you mean with "uses". The function itself was introduced in r253159, when 10.x was still -CURRENT, and merged to 9.x in r253222. But the function was never in Version.map earlier, so it was not exposed.

If so then we should check that old binaries still run with the new .so, otherwise I think it's fine.

Bug 200863 was specifically about 10-stable, where it caused "undefined reference to `__cxa_deleted_virtual'". So I think we can safely assume nothing will break by adding it. :-)

Generally, I'd been following the policy that symbols that were not present in libsupc++ in 8.x go in the CXXRT version namespace to avoid conflicts, but I don't see a problem with putting them in the other namespace as well. I think (hope?) that libstdc++ in ports is linking libcxxrt instead of libsupc++, so it shouldn't matter what we're doing, as long as we're self-consistent.

Ports gcc uses the same approach as a hand-built gcc, it dumps the libsupc++ object files directly into libstdc++.so:

$ readelf -aW /usr/local/lib/gcc49/libstdc++.so.6 | grep cxa_deleted
  2402: 0004c1c0    36 FUNC    GLOBAL DEFAULT   11 __cxa_deleted_virtual@@CXXABI_1.3.6
  3531: 0004c1c0    36 FUNC    GLOBAL DEFAULT   11 __cxa_deleted_virtual