https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jonathan Wakely <r...@gcc.gnu.org>: https://gcc.gnu.org/g:c2fc1702cb3a3d5cc9c40de47f63b4c8f3f1d09c commit r12-46-gc2fc1702cb3a3d5cc9c40de47f63b4c8f3f1d09c Author: Philippe Blain <levraiphilippebl...@gmail.com> Date: Fri Mar 12 19:26:46 2021 -0500 libstdc++: Install libstdc++*-gdb.py more robustly [PR 99453] In order for GDB to auto-load the pretty printers, they must be installed as "libstdc++.$ext-gdb.py", where 'libstdc++.$ext' is the name of the object file that is loaded by GDB [1], i.e. the libstdc++ shared library. The approach taken in libstdc++-v3/python/Makefile.am is to loop over files matching 'libstdc++*' in $(DESTDIR)$(toolexeclibdir) and choose the last file matching that glob that is not a symlink, the Libtool '*.la' file or a Python file. That works fine for ELF targets where the matching names are: libstdc++.a libstdc++.so libstdc++.so.6 libstdc++.so.6.0.29 But not for macOS with: libstdc++.6.dylib libstdc++.a Or MinGW with: libstdc++-6.dll libstdc++.dll.a Try to make a better job at installing the pretty printers with the correct name by copying the approach taken by isl [2], that is, using a sed invocation on the Libtool-generated 'libstdc++.la' to read the correct name for the current platform. [1] https://sourceware.org/gdb/onlinedocs/gdb/objfile_002dgdbdotext-file.html [2] https://repo.or.cz/isl.git/blob/HEAD:/Makefile.am#l611 libstdc++-v3/ChangeLog: PR libstdc++/99453 * python/Makefile.am: Install libstdc++*-gdb.py more robustly. * python/Makefile.in: Regenerate. Co-authored-by: Jonathan Wakely <jwak...@redhat.com>
