[Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming

[Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

            Bug ID: 99453
           Summary: libstdc++*-gdb.py installation depends on library
                    naming
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

libstdc++-v3/python/Makefile.am does:

install-data-local: gdb.py
        @$(mkdir_p) $(DESTDIR)$(toolexeclibdir)
## We want to install gdb.py as SOMETHING-gdb.py.  SOMETHING is the
## full name of the final library.  We want to ignore symlinks, the
## .la file, and any previous -gdb.py file.  This is inherently
## fragile, but there does not seem to be a better option, because
## libtool hides the real names from us.
        @here=`pwd`; cd $(DESTDIR)$(toolexeclibdir); \
          for file in libstdc++.*; do \
            case $$file in \
              *-gdb.py) ;; \
              *.la) ;; \
              *) if test -h $$file; then \
                   continue; \
                 fi; \
                 libname=$$file;; \
            esac; \
          done; \
        cd $$here; \
        echo " $(INSTALL_DATA) gdb.py
$(DESTDIR)$(toolexeclibdir)/$$libname-gdb.py"; \
        $(INSTALL_DATA) gdb.py $(DESTDIR)$(toolexeclibdir)/$$libname-gdb.py


This will use the last matching file for the libstdc++* glob. 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

We need a better way to find the dynamic library, whether that's the so.6.0.29
or the .dylib or the .dll, that doesn't depend on the shell's alphabetic sort
for the pattern. As the comment says, libtool doesn't give us that info, but we
can still do better.

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iains at gcc dot gnu.org

--- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
and we can't skip .a because that's the right suffix for AIX, correct?

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yup

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[levraiphilippeblain at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

Philippe Blain <levraiphilippeblain at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |levraiphilippeblain at gmail dot c
                   |                            |om

--- Comment #3 from Philippe Blain <levraiphilippeblain at gmail dot com> ---
I searched for other *-gdb.py files on my system and looked at the
build process for these projetcs, and found one interesting example
for libisl, where it looks like they rely on the libtool *.la file
to get the right name for the (shared or not) library:

https://repo.or.cz/isl.git/blob/HEAD:/Makefile.am#l611

Maybe something similar could be done?

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[levraiphilippeblain at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

--- Comment #4 from Philippe Blain <levraiphilippeblain at gmail dot com> ---
Patch posted: 
- https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567650.html
(gcc-patches) 
- https://gcc.gnu.org/pipermail/libstdc++/2021-April/052291.html (libstdc++)

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[cvs-commit at gcc dot gnu.org]

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 <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:c2fc1702cb3a3d5cc9c40de47f63b4c8f3f1d09c

commit r12-46-gc2fc1702cb3a3d5cc9c40de47f63b4c8f3f1d09c
Author: Philippe Blain <levraiphilippeblain@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 <jwakely@redhat.com>

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-04-21
   Target Milestone|---                         |12.0

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed on trunk by Philippe's patch. This is worth backporting after some time
to bake, but I don't expect problems given that isl already uses this solution.

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:dbb87d6a9c37c8eca80d77782717a8144515c16d

commit r11-8381-gdbb87d6a9c37c8eca80d77782717a8144515c16d
Author: Philippe Blain <levraiphilippeblain@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 <jwakely@redhat.com>
    (cherry picked from commit c2fc1702cb3a3d5cc9c40de47f63b4c8f3f1d09c)

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.0                        |11.2

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[raj.khem at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

Khem Raj <raj.khem at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |raj.khem at gmail dot com

--- Comment #8 from Khem Raj <raj.khem at gmail dot com> ---
this change seems to cause a regression when build baremetal toolchain, it ends
up generating /usr/lib/-gdb.py instead of libstdc++-gdb.py, the gcc tuple to
build is arm-none-eabi

the libstdc++.la looks like this

# libstdc++.la - a libtool library file
# Generated by libtool (GNU libtool 1.3134 2009-11-29) 2.2.7a
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname=''

# Names of this library.
library_names=''

# The name of the static archive.
old_library='libstdc++.a'

# Linker flags that can not go in dependency_libs.
inherited_linker_flags=''

# Libraries that this one depends upon.
dependency_libs=' -lm'

# Names of additional weak libraries provided by this library
weak_library_names=''

# Version information for libstdc++.
current=6
age=0
revision=29

# Is this an already installed library?
installed=no

# Should we warn about portability when linking against -modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/usr/lib'

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Khem Raj from comment #8)
> this change seems to cause a regression when build baremetal toolchain, it
> ends up generating /usr/lib/-gdb.py instead of libstdc++-gdb.py,

Is that really what it used to generate? Or was it libstdc++.a-gdb.py ?

Presumably this happens for --disable-shared as well, it's not specific to
baremetal.

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[ross at burtonini dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

--- Comment #10 from Ross Burton <ross at burtonini dot com> ---
I can confirm that before this fix the file was called libstdc++.a-gdb.py

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Thanks! I think we just need to use the old_library name if library_names is
empty.

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Like so:

        @libname=`sed -ne "/^library_names=/{s/.*='//;s/'$$//;s/ .*//;p;}" \
                  $(DESTDIR)$(toolexeclibdir)/libstdc++.la`; \
        libname='' ; \
        if [ -z "$$libname" ]; then \
          libname=`sed -ne "/^old_library=/{s/.*='//;s/'$$//;s/ .*//;p;}" \
                  $(DESTDIR)$(toolexeclibdir)/libstdc++.la`; \
        fi; \
        echo " $(INSTALL_DATA) gdb.py
$(DESTDIR)$(toolexeclibdir)/$$libname-gdb.py"; \
        $(INSTALL_DATA) gdb.py $(DESTDIR)$(toolexeclibdir)/$$libname-gdb.py

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #12)
> Like so:
> 
> 	@libname=`sed -ne "/^library_names=/{s/.*='//;s/'$$//;s/ .*//;p;}" \
> 	          $(DESTDIR)$(toolexeclibdir)/libstdc++.la`; \
> 	libname='' ; \

Oops, that line was present while testing, but shouldn't be there!

> 	if [ -z "$$libname" ]; then \
> 	  libname=`sed -ne "/^old_library=/{s/.*='//;s/'$$//;s/ .*//;p;}" \
> 		  $(DESTDIR)$(toolexeclibdir)/libstdc++.la`; \
> 	fi; \
> 	echo " $(INSTALL_DATA) gdb.py
> $(DESTDIR)$(toolexeclibdir)/$$libname-gdb.py"; \
> 	$(INSTALL_DATA) gdb.py $(DESTDIR)$(toolexeclibdir)/$$libname-gdb.py

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[levraiphilippeblain at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

--- Comment #14 from Philippe Blain <levraiphilippeblain at gmail dot com> ---
Sorry for that regression, I did not have access to a lot of platforms to test.
I agree that falling back to 'old_library' if 'library_names' is empty would be
a good fix.

Out of curiosity, do you know what GDB does with this libstdc++.a-gdb.py ? It's
there so it can be loaded manually I guess, but the auto-load behaviour can't
work for static libraries (or I'm missing something?)

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Philippe Blain from comment #14)
> Out of curiosity, do you know what GDB does with this libstdc++.a-gdb.py ?
> It's there so it can be loaded manually I guess, but the auto-load behaviour
> can't work for static libraries (or I'm missing something?)

Yes, I think it an only be used by loading it manually.

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:9f7bc160b4a0f27dce248d1226e3ae7104b0e67b

commit r12-1141-g9f7bc160b4a0f27dce248d1226e3ae7104b0e67b
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Jun 1 11:00:16 2021 +0100

    libstdc++: Fix installation of python hooks [PR 99453]

    When no shared library is installed, the new code to determine the name
    of the -gdb.py file yields an empty string. Use the name of the static
    library in that case.

    libstdc++-v3/ChangeLog:

            PR libstdc++/99453
            * python/Makefile.am: Use archive name for printer hook if no
            dynamic library name is available.
            * python/Makefile.in: Regenerate.

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:ad4c21f0f59b52357019148ec94d767aa2acd8f2

commit r11-8500-gad4c21f0f59b52357019148ec94d767aa2acd8f2
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Jun 1 11:00:16 2021 +0100

    libstdc++: Fix installation of python hooks [PR 99453]

    When no shared library is installed, the new code to determine the name
    of the -gdb.py file yields an empty string. Use the name of the static
    library in that case.

    libstdc++-v3/ChangeLog:

            PR libstdc++/99453
            * python/Makefile.am: Use archive name for printer hook if no
            dynamic library name is available.
            * python/Makefile.in: Regenerate.

    (cherry picked from commit 9f7bc160b4a0f27dce248d1226e3ae7104b0e67b)

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:5b4b18b892278380cdb303c097466009914b828e

commit r10-9884-g5b4b18b892278380cdb303c097466009914b828e
Author: Philippe Blain <levraiphilippeblain@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 <jwakely@redhat.com>
    (cherry picked from commit c2fc1702cb3a3d5cc9c40de47f63b4c8f3f1d09c)

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:a937d0269c1202326a74965329159d90f176438a

commit r10-9885-ga937d0269c1202326a74965329159d90f176438a
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Jun 1 11:00:16 2021 +0100

    libstdc++: Fix installation of python hooks [PR 99453]

    When no shared library is installed, the new code to determine the name
    of the -gdb.py file yields an empty string. Use the name of the static
    library in that case.

    libstdc++-v3/ChangeLog:

            PR libstdc++/99453
            * python/Makefile.am: Use archive name for printer hook if no
            dynamic library name is available.
            * python/Makefile.in: Regenerate.

    (cherry picked from commit 9f7bc160b4a0f27dce248d1226e3ae7104b0e67b)

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.2                        |10.4
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #20 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for 10.4 and 11.2, I'm not going to backport it to gcc-9.

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453

--- Comment #21 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #0)
> This will use the last matching file for the libstdc++* glob. 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
> 
> We need a better way to find the dynamic library, whether that's the
> so.6.0.29 or the .dylib or the .dll, that doesn't depend on the shell's
> alphabetic sort for the pattern. As the comment says, libtool doesn't give
> us that info, but we can still do better.

Hmm, this isn't fixed for mingw because the libtool libstdc++.la file has:

# The name that we can dlopen(3).
dlname='libstdc++-6.dll'

# Names of this library.
library_names='libstdc++.dll.a'

# The name of the static archive.
old_library='libstdc++.a'


This means we still choose libstdc++.dll.a-gdb.py as the hook name, which is
still wrong. Yay for libtool.