[gcc-13 PATCH 0/2] Replace libstdc++_libbacktrace.a with libstdc++exp.a

[Jonathan Wakely <jwakely@redhat.com>]

The first patch is a backport from trunk to fix the fact that I messed
up the change to add all symbols from libstdc++fs.a into libstdc++exp.a,
which was backported as r13-8207-g17acf9fbeb10d7. The change builds
libstdc++fs.a twice, once to install it and once as a convenience
library to be included into libstdc++exp.a. That change already works
fine on trunk, so should be fine on gcc-13 too.

The second patch is not a backport but is needed for the branch to
ensure that libstdc++exp.a also provides the symbols for
libstdc++_libbacktrace.a but without removing libstdc++_libbacktrace.a
itself. On trunk I removed it and put all its symbols in libstdc++exp.a,
but on the branch we don't want to stop installing that static lib
halfway through the gcc-13 release series, as it will break makefiles
that are using -lstdc++_libbacktrace to get those symbols.

Because libstdc++-v3/src/libbacktrace/Makefile.am is more complicated
than libstdc++-v3/src/filesystem/Makefile.am and because I don't know
what all the _LIBADD etc. variables do, I'm not sure exactly how to do
the "build it twice, once for installation and once as a convenience
library" thing. So instead what this patch does is change it to a
convenience library (as is done on trunk) but then also create a symlink
with the old installed name, pointing to libstdc++exp.a, so that
using -lstdc++_libbacktrace still works. The symlink is created using
$(LN_S) so for targets that don't support symlinks it's just a copy.

One gotcha is that if you do 'make install' over a pre-existing gcc-13
installation, the new symlinks for libstdc++_libbacktrace.{a,la} won't
be created, because there are already real files with those names. That
won't affect users installing gcc-13.3.0 afresh, it would only affect
people who've been building 13.2.1 from git or from snapshots. Apart
from some errors printed to stderr (and ignored by make) it won't really
matter, because the existing regular files provide the same symbols
anyway.

Does this look reasonable, and done correctly?

Or should I bite the bullet and figure out how to properly adjust
src/libbacktrace/Makefile.am to create an installable library and a
convenience library in parallel? Would I need to copy every
libstdc___libbacktrace_la_FOO variable to create a corresponding
libstdc___libbacktraceconvenience_la_FOO variable?

One advantage of the symlink approach is that we don't increase the
installed footprint of gcc-13 by duplicating all the backtrace symbols
in two static archives. We could even consider making libstdc++fs.a a
symlink to libstdc++exp.a as well, on trunk and gcc-13, to stop
duplicating those symbols.

-- >8 --

Jonathan Wakely (2):
  libstdc++: Fix libstdc++exp.a so it really does contain Filesystem TS
    symbols
  libstdc++: Add libstdc++_libbacktrace.a to libstdc++exp

 libstdc++-v3/src/experimental/Makefile.am |  7 +-
 libstdc++-v3/src/experimental/Makefile.in | 27 ++++---
 libstdc++-v3/src/filesystem/Makefile.am   |  4 ++
 libstdc++-v3/src/filesystem/Makefile.in   | 37 ++++++++--
 libstdc++-v3/src/libbacktrace/Makefile.am |  2 +-
 libstdc++-v3/src/libbacktrace/Makefile.in | 86 ++++-------------------
 6 files changed, 73 insertions(+), 90 deletions(-)

-- 
2.44.0