Re: r147958 - in /trunk/libstdc++-v3: ChangeLog Mak...

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 28 May 2009, tromey@gcc.gnu.org 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
> Log:
> 2009-05-28  Tom Tromey  <tromey@redhat.com>
> 	    Phil Muldoon  <pmuldoon@redhat.com>
> 	    Jonathan Wakely  <jwakely.gcc@gmail.com>
> 
> 	* 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:
    sys.path.insert(0, dir)

and Makefile.am does

        sed -e 's,@dir@,$(pythondir),' < $(srcdir)/hook.in > $@

where

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 
here?

-- 
Joseph S. Myers
joseph@codesourcery.com