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

[Abe <abe149 at gmail dot com>]

Dear all,

As part of my [CS PhD student] research that is using libstdc++, I
want to be able to run the test suite over a separately-modified copy
of libstdc++.  To accomplish this, AFAIK I need to modify either the
compiler path or the C++ library include paths that will be used to
compile the tests.  The compiler path would do that for me as well b/c
I have kludge scripts in place that take the passed-in parameters and
do something like this:

  -nostdinc++ "$@" -I$LIBRARY_TO_USE -I$LIBRARY_TO_USE/backward
  -I$LIBRARY_TO_USE/$GCC_CPLUSPLUS_INCLUDES_HOST_SUBDIR_NAME -I/usr/include

â after setting the appropriate variables, e.g. on the 64-bit [Intel
Core 2 Duo] Mac OS X 10.6.8 machine I`m doing this on I set
GCC_CPLUSPLUS_INCLUDES_HOST_SUBDIR_NAME to
"x86_64-apple-darwin10.8.0".


I`ve tried editing the file that my GCC [4.7.2] built originally had
at the path "/usr/src/gcc-4.7.2/x86_64-apple-darwin10.8.0/libstdc++-v3/testsuite/Makefile",
doing stuff like this:

  â replace the predefined value of "CXX"
["/usr/src/gcc-4.7.2/host-x86_64-apple-darwin10.8.0/gcc/xgcc <lots of
options>"]
    with a path to one of my kludge scripts, as I described above
["-nostdinc++" etc.]

  â replace the predefined value of "CXXCPP"
["/usr/src/gcc-4.7.2/host-x86_64-apple-darwin10.8.0/gcc/xgcc <lots of
options> -E"]
    with a path to one of my kludge scripts plus the preprocessor-only
option "-E"

  â replace the predefined value of "GLIBCXX_INCLUDES"
    ["-I/usr/src/gcc-4.7.2/x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0
â"]
    with a similar string representing paths to the following entry
points into my modified copy of libstdc++ 4.7.2:
    the top level, "<top level>/backward", and "<top
level>/x86_64-apple-darwin10.8.0"

  [I also set "CC" to "/usr/bin/false", just to try to force it to
break if it`s using the C compiler instead of the C++ one for some
reason]


Unfortunately, none of the above seems to have done the trick: when
running "make check" in the directory with the modified Makefile, it
still seems to be doing everything the way it normally does, judging
by the output in "libstdc++.log".

Here`s the start of the console output I get from "make check"; it`s
probably normal-looking to people who have used this test suite
before:



  make  check-DEJAGNU
  AR="ar"; export AR; \
        RANLIB="ranlib"; export RANLIB; \
        if [ -z "" ] \
            && [ "" = "-j" ]; then \
          make  check-DEJAGNUnormal0 check-DEJAGNUnormal1
check-DEJAGNUnormal2 check-DEJAGNUnormal3 check-DEJAGNUnormal4
check-DEJAGNUnormal5 check-DEJAGNUnormal6 check-DEJAGNUnormal7
check-DEJAGNUnormal8 check-DEJAGNUnormal9; \

  [lots more script code, not copy+pasted]

  WARNING: Couldn't find the global config file.
  Test Run By Abe on Wed Mar 20 12:49:07 2013
  Native configuration is x86_64-apple-darwin10.8.0

                === libstdc++ tests ===

  Schedule of variations:
    unix

  Running target unix
  Using /usr/local/share/dejagnu/baseboards/unix.exp as board
description file for target.
  Using /usr/local/share/dejagnu/config/unix.exp as generic interface
file for target.
  Using /usr/src/gcc-4.7.2/libstdc++-v3/testsuite/config/default.exp
as tool-and-target-specific interface file.
  Running /usr/src/gcc-4.7.2/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ...
  Running /usr/src/gcc-4.7.2/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...



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?

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?  [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.]

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.

Regards,

Abe