* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
@ 2021-03-07 16:21 ` iains at gcc dot gnu.org
2021-03-07 16:34 ` redi at gcc dot gnu.org
` (20 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: iains at gcc dot gnu.org @ 2021-03-07 16:21 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
2021-03-07 16:21 ` [Bug libstdc++/99453] " iains at gcc dot gnu.org
@ 2021-03-07 16:34 ` redi at gcc dot gnu.org
2021-03-08 21:29 ` levraiphilippeblain at gmail dot com
` (19 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-07 16:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yup
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
2021-03-07 16:21 ` [Bug libstdc++/99453] " iains at gcc dot gnu.org
2021-03-07 16:34 ` redi at gcc dot gnu.org
@ 2021-03-08 21:29 ` levraiphilippeblain at gmail dot com
2021-04-03 19:05 ` levraiphilippeblain at gmail dot com
` (18 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: levraiphilippeblain at gmail dot com @ 2021-03-08 21:29 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (2 preceding siblings ...)
2021-03-08 21:29 ` levraiphilippeblain at gmail dot com
@ 2021-04-03 19:05 ` levraiphilippeblain at gmail dot com
2021-04-21 15:55 ` cvs-commit at gcc dot gnu.org
` (17 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: levraiphilippeblain at gmail dot com @ 2021-04-03 19:05 UTC (permalink / raw)
To: gcc-bugs
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++)
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (3 preceding siblings ...)
2021-04-03 19:05 ` levraiphilippeblain at gmail dot com
@ 2021-04-21 15:55 ` cvs-commit at gcc dot gnu.org
2021-04-21 15:56 ` redi at gcc dot gnu.org
` (16 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-21 15:55 UTC (permalink / raw)
To: gcc-bugs
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>
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (4 preceding siblings ...)
2021-04-21 15:55 ` cvs-commit at gcc dot gnu.org
@ 2021-04-21 15:56 ` redi at gcc dot gnu.org
2021-05-11 19:50 ` cvs-commit at gcc dot gnu.org
` (15 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-04-21 15:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (5 preceding siblings ...)
2021-04-21 15:56 ` redi at gcc dot gnu.org
@ 2021-05-11 19:50 ` cvs-commit at gcc dot gnu.org
2021-05-11 20:01 ` redi at gcc dot gnu.org
` (14 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-05-11 19:50 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (6 preceding siblings ...)
2021-05-11 19:50 ` cvs-commit at gcc dot gnu.org
@ 2021-05-11 20:01 ` redi at gcc dot gnu.org
2021-05-26 17:07 ` raj.khem at gmail dot com
` (13 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-05-11 20:01 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (7 preceding siblings ...)
2021-05-11 20:01 ` redi at gcc dot gnu.org
@ 2021-05-26 17:07 ` raj.khem at gmail dot com
2021-05-27 10:07 ` redi at gcc dot gnu.org
` (12 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: raj.khem at gmail dot com @ 2021-05-26 17:07 UTC (permalink / raw)
To: gcc-bugs
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'
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (8 preceding siblings ...)
2021-05-26 17:07 ` raj.khem at gmail dot com
@ 2021-05-27 10:07 ` redi at gcc dot gnu.org
2021-05-27 10:16 ` ross at burtonini dot com
` (11 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-05-27 10:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (9 preceding siblings ...)
2021-05-27 10:07 ` redi at gcc dot gnu.org
@ 2021-05-27 10:16 ` ross at burtonini dot com
2021-05-27 10:18 ` redi at gcc dot gnu.org
` (10 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: ross at burtonini dot com @ 2021-05-27 10:16 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (10 preceding siblings ...)
2021-05-27 10:16 ` ross at burtonini dot com
@ 2021-05-27 10:18 ` redi at gcc dot gnu.org
2021-05-27 10:26 ` redi at gcc dot gnu.org
` (9 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-05-27 10:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (11 preceding siblings ...)
2021-05-27 10:18 ` redi at gcc dot gnu.org
@ 2021-05-27 10:26 ` redi at gcc dot gnu.org
2021-05-27 10:30 ` redi at gcc dot gnu.org
` (8 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-05-27 10:26 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (12 preceding siblings ...)
2021-05-27 10:26 ` redi at gcc dot gnu.org
@ 2021-05-27 10:30 ` redi at gcc dot gnu.org
2021-05-27 12:14 ` levraiphilippeblain at gmail dot com
` (7 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-05-27 10:30 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (13 preceding siblings ...)
2021-05-27 10:30 ` redi at gcc dot gnu.org
@ 2021-05-27 12:14 ` levraiphilippeblain at gmail dot com
2021-05-27 16:39 ` redi at gcc dot gnu.org
` (6 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: levraiphilippeblain at gmail dot com @ 2021-05-27 12:14 UTC (permalink / raw)
To: gcc-bugs
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?)
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (14 preceding siblings ...)
2021-05-27 12:14 ` levraiphilippeblain at gmail dot com
@ 2021-05-27 16:39 ` redi at gcc dot gnu.org
2021-06-01 12:29 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-05-27 16:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (15 preceding siblings ...)
2021-05-27 16:39 ` redi at gcc dot gnu.org
@ 2021-06-01 12:29 ` cvs-commit at gcc dot gnu.org
2021-06-02 13:43 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-06-01 12:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (16 preceding siblings ...)
2021-06-01 12:29 ` cvs-commit at gcc dot gnu.org
@ 2021-06-02 13:43 ` cvs-commit at gcc dot gnu.org
2021-06-03 14:57 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-06-02 13:43 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (17 preceding siblings ...)
2021-06-02 13:43 ` cvs-commit at gcc dot gnu.org
@ 2021-06-03 14:57 ` cvs-commit at gcc dot gnu.org
2021-06-03 14:57 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-06-03 14:57 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (18 preceding siblings ...)
2021-06-03 14:57 ` cvs-commit at gcc dot gnu.org
@ 2021-06-03 14:57 ` cvs-commit at gcc dot gnu.org
2021-06-03 14:59 ` redi at gcc dot gnu.org
2022-05-09 16:19 ` redi at gcc dot gnu.org
21 siblings, 0 replies; 23+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-06-03 14:57 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (19 preceding siblings ...)
2021-06-03 14:57 ` cvs-commit at gcc dot gnu.org
@ 2021-06-03 14:59 ` redi at gcc dot gnu.org
2022-05-09 16:19 ` redi at gcc dot gnu.org
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-06-03 14:59 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
2021-03-07 16:04 [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming redi at gcc dot gnu.org
` (20 preceding siblings ...)
2021-06-03 14:59 ` redi at gcc dot gnu.org
@ 2022-05-09 16:19 ` redi at gcc dot gnu.org
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2022-05-09 16:19 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread