This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 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 
library path.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]