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.
