This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: r147958 - in /trunk/libstdc++-v3: ChangeLog Mak...
- From: Tom Tromey <tromey at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Fri, 29 May 2009 12:44:23 -0600
- Subject: Re: r147958 - in /trunk/libstdc++-v3: ChangeLog Mak...
- References: <20090528171422.508.qmail@sourceware.org> <Pine.LNX.4.64.0905282258430.24872@digraph.polyomino.org.uk>
- Reply-to: Tom Tromey <tromey at redhat dot com>
>>>>> "Joseph" == Joseph S Myers <joseph@codesourcery.com> writes:
Joseph> I don't see a recent posting of this to gcc-patches (where all
Joseph> libstdc++ patches should be posted as well as the libstdc++
Joseph> list)
Sorry, I was unaware of this requirement.
I will remember in the future.
Joseph> - that is, an absolute, unrelocated path containing the
Joseph> configured prefix. If the toolchain has been moved from the
Joseph> configured prefix (and for this I think you can assume GCC and
Joseph> GDB are moved together)
FWIW I don't think this assumption is warranted.
Joseph> I'm also concerned about the code that does
Joseph> libname=`cd $(toolexeclibdir) && ls -r libstdc++* | fgrep -v gdb.py | sed 1q`; \
Yeah, that does seem dubious.
Joseph> and while I'm not sure exactly what this code is trying to
Joseph> compute
The -gdb.py "hook" file must be named after the real name of the
objfile -- that is, after symlinks are resolved. Finding this real
name is tricky because libtool hides it from us.
The appended patch attempts to address these issues, plus PR 40289:
* It changes the name of the python datadir to be versioned.
I used "gcc" rather than "libstdc++" both because the gcc version
number is more readily available, and because it leaves open the
possibility of installing other gcc-specific pretty-printers.
* It now computes the new module path relative to the objfile. This
is better, in that moving the whole tree should work. However, it
assumes that datadir is always available as $libdir/../share.
I'm not sure whether that is ok.
* It rewrites the install-data-local rule to use an explicit loop.
I am still not extremely happy about this code, but I don't know
what else to do.
Please review.
Tom
ChangeLog:
2009-05-29 Tom Tromey <tromey@redhat.com>
PR libstdc++/40289:
* python/Makefile.in: Rebuild.
* python/hook.in: Compute module path relative to objfile.
* python/Makefile.am (pythondir): Redefine.
(gdb.py): Subst gcc_version, not pythondir.
(install-data-local): Rewrite.
Index: python/hook.in
===================================================================
--- python/hook.in (revision 147958)
+++ python/hook.in (working copy)
@@ -16,9 +16,14 @@
import sys
import gdb
+import os.path
-# Update module path.
-dir = '@dir@'
+# Update module path. We assume that the library files are at a fixed
+# position relative to the objfile.
+datadir = 'gcc-@gcc_version@/python'
+objfile = gdb.current_objfile ().filename
+dir = os.path.join (os.path.dirname (objfile), '../share', datadir)
+
if not dir in sys.path:
sys.path.insert(0, dir)
Index: python/Makefile.am
===================================================================
--- python/Makefile.am (revision 147958)
+++ python/Makefile.am (working copy)
@@ -24,7 +24,7 @@
include $(top_srcdir)/fragment.am
## Where to install the module code.
-pythondir = $(pkgdatadir)/python
+pythondir = $(datadir)/gcc-$(gcc_version)/python
all-local: gdb.py
@@ -34,10 +34,26 @@
libstdcxx/__init__.py
gdb.py: hook.in Makefile
- sed -e 's,@dir@,$(pythondir),' < $(srcdir)/hook.in > $@
+ sed -e 's,@gcc_version@,$(gcc_version),' < $(srcdir)/hook.in > $@
install-data-local: gdb.py
@$(mkdir_p) $(DESTDIR)$(toolexeclibdir)
- @libname=`cd $(toolexeclibdir) && ls -r libstdc++* | fgrep -v gdb.py | sed 1q`; \
+## 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 $(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