public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming
@ 2021-03-07 16:04 redi at gcc dot gnu.org
  2021-03-07 16:21 ` [Bug libstdc++/99453] " iains at gcc dot gnu.org
                   ` (21 more replies)
  0 siblings, 22 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-07 16:04 UTC (permalink / raw)
  To: gcc-bugs

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.

^ permalink raw reply	[flat|nested] 23+ messages in thread
end of thread, other threads:[~2022-05-09 16:19 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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
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
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
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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).