This is the mail archive of the
mailing list for the GCC project.
Re: r147958 - in /trunk/libstdc++-v3: ChangeLog Mak...
On Fri, 29 May 2009, Tom Tromey wrote:
> 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.
It's not ideal, but given multilib arrangements it can work in some cases
where relocating relative to the object file won't.
> * 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.
There are two problems:
* You can't assume it's $libdir/../share. For one thing, $libdir may be a
deeply nested subdirectory when this libstdc++ build directory was
configured for a non-default multilib; for another, configure options may
change the relation bewteen the paths further. The aim should be to look
at the relation between the two configured paths (libdir and datadir in
this case) and apply the same relation to the path you are determining at
runtime, without presuming the relation is "../share".
* Shared libraries are naturally copied from one place to another, with
the -gdb.py file copied along with them. In particular, for a cross
compiler to a GNU/Linux target they would be copied to the /usr/lib
directory in a sysroot directory that is the image of the target's root
filesystem and may be referenced with --sysroot in compilation commands,
"set sysroot" in GDB, etc.; in this case, do you want to require all the
share/ files (which may only be of use to a cross-debugger, not on the
target) to be copied there as well? This is a case where relocating based
on where GDB is installed may work better than relocating based on the
You might reasonably say it's only GCC's job to handle the libraries in
the relative arrangements in which GCC installs them and that when they
are copied to a sysroot the -gdb.py file should have its relative paths
adjusted accordingly depending on where the copier puts the other Python
files. But you do at least need to ensure if you do this that the paths
are correct for the files where GCC installs them, whatever the relation
between libdir and datadir for the multilib being installed.
Joseph S. Myers