This is the mail archive of the
mailing list for the GCC project.
Re: r147958 - in /trunk/libstdc++-v3: ChangeLog Mak...
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: tromey at gcc dot gnu dot org
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Thu, 28 May 2009 23:09:47 +0000 (UTC)
- Subject: Re: r147958 - in /trunk/libstdc++-v3: ChangeLog Mak...
- References: <firstname.lastname@example.org>
On Thu, 28 May 2009, email@example.com wrote:
> Author: tromey
> Date: Thu May 28 17:14:18 2009
> New Revision: 147958
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147958
> 2009-05-28 Tom Tromey <firstname.lastname@example.org>
> Phil Muldoon <email@example.com>
> Jonathan Wakely <firstname.lastname@example.org>
> * python/Makefile.in, , python/libstdcxx/__init__.py,
> python/libstdcxx/v6/__init__.py, python/libstdcxx/v6/printers.py,
> python/hook.in, python/Makefile.am: New files.
> * configure, Makefile.in: Rebuild.
> * acinclude.m4 (glibcxx_SUBDIRS): Add python.
> * Makefile.am (SUBDIRS): Add python.
I don't see a recent posting of this to gcc-patches (where all libstdc++
patches should be posted as well as the libstdc++ list) and if there was
an older one I must have missed the point I'm about to make, so I'm making
it now in reply to the gcc-cvs message:
The file hook.in does
dir = '@dir@'
if not dir in sys.path:
and Makefile.am does
sed -e 's,@dir@,$(pythondir),' < $(srcdir)/hook.in > $@
pythondir = $(pkgdatadir)/python
- that is, an absolute, unrelocated path containing the configured prefix.
If the toolchain has been moved from the configured prefix (and for this I
think you can assume GCC and GDB are moved together) then the code needs
to relocate the path before searching there for these Python sources. In
libiberty terms this is make_relative_prefix (or the GDB wrapper
relocate_path); I don't know how this relates to the Python bindings, but
any time you add new hardcoded absolute paths to files installed by GCC
you need to ensure they work properly with relocation.
I'm also concerned about the code that does
libname=`cd $(toolexeclibdir) && ls -r libstdc++* | fgrep -v gdb.py | sed 1q`; \
and while I'm not sure exactly what this code is trying to compute, ls -r
uses reverse collating sequence of the current locale and I don't see
anything here to ensure the C locale is used; are you sure that the order
given by the installer's locale always has whatever property you require
Joseph S. Myers