Re: a request with help with modifying the libstdc++ test suite harness to analyze a copy of libstdc++ other than the one in the source unpacking and build directory

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 20 March 2013 18:13, Abe wrote:
> From what I`ve read about DejaGNU, "WARNING: Couldn't find the global
> config file." is not something to worry about.  OTOH, is a "global
> config file" something that would allow me to achieve my objective[s]
> WRT running the tests over a different copy of the GCC STL?  If not,
> then should I be trying to do something to the "<…>.exp" files listed
> in the output?

I don't think so.


I know it *used* to be possible to run the tests against an installed
compiler, but I can't say if it still works as intended.

The docs at http://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html say:

"You can run the tests with a compiler and library that have already
been installed. Make sure that the compiler (e.g., g++) is in your
PATH. If you are using shared libraries, then you must also ensure
that the directory containing the shared version of libstdc++ is in
your LD_LIBRARY_PATH, or equivalent. If your GCC source tree is at
/path/to/gcc, then you can run the tests as follows:

runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite

The testsuite will create a number of files in the directory in which
you run this command,. Some of those files might use the same name as
files created by other testsuites (like the ones for GCC and G++), so
you should not try to run all the testsuites in parallel from the same
directory. "

Have you tried that method? i.e. not running 'make check' within the
build tree (which causes it to use the just-built compiler) but
launching DejaGNU from another location, where it finds GCC in your
PATH?


> Also probably relevant: the modified GCC STL I want to run the test
> suite over is modified as a copy of the libstdc++ directory I got
> after doing "make install"; I realized while writing this message that
> the difference in directory layout between the copy of libstdc++ in
> the source tarball extraction and the copy that is installed might
> make the test suite not work over the modified copy as-is.  Your
> thoughts on that, please?

It shouldn't matter as long as the compiler can find the headers that
are included by the tests.

>  [Also: I`m guessing it`s _not_ the case
> that some test driver code is inspecting my proposed alternative
> directories, finding the contents/layout different than expected, and
> then reverting to the defaults directories for the platform -- I`ve
> never seen test suite scripts that smart before, IIRC, but if this
> code _does_ know how to do that, then somebody please tell me.]

That is not the case.

> If needed, is it possible to set up a mapping from the installed
> libstdc++ directory layout back to the source-and-build libstdc++
> directory layout, e.g. via symlinks?  It would _really_ help me if I
> wouldn`t have to re-do my modifications and maintain two copies of
> each mod. set, supposedly with the same mod.s but with different
> layout, in order to be able to run both the test suite and other
> experiments.
>
> My apologies for the length of this message; I figured it would be
> better to get all the background information into the request for help
> rather than having people need to "drag it out of me" before they can
> help.

Thank you, that does make it easier :-)