This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Testsuite README
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Tue, 3 Apr 2012 20:30:41 +0530
- Subject: Re: [PATCH] Testsuite README
- References: <20120403202821.58328b92@spoyarek>
On Tue, 3 Apr 2012 20:28:21 +0530
Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
> actually putting out any content for review. Here's a patch with just
> that.
Oops, forgot to add the patch. Here it is.
--
Siddhesh
>From ef8d0b0222fe55a36066564e925da70b993a36d2 Mon Sep 17 00:00:00 2001
From: Siddhesh Poyarekar <siddhesh@redhat.com>
Date: Tue, 3 Apr 2012 20:16:26 +0530
Subject: [PATCH] Instructions for test environment setup
---
README.testing | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 51 insertions(+), 0 deletions(-)
create mode 100644 README.testing
diff --git a/README.testing b/README.testing
new file mode 100644
index 0000000..5009784
--- /dev/null
+++ b/README.testing
@@ -0,0 +1,51 @@
+The glibc testsuite can be executed by issuing the 'make check'
+command from the build directory. The testsuite halts whenever it
+encounters an error. One may continue by simply issuing the 'make
+check' command again, but it is recommended that testsuite failures be
+studied seriously and if necessary, reported in bugzilla.
+
+A typical test case writes out a file with a .out extension in the
+build directory, that contains the output of the test. This file may
+be inspected in case of a test case failure to determine what the
+problem. If you report a test case failure in bugzilla, be sure to
+include the contents of the relevant .out file as well.
+
+To repeat the test that failed, simply remove the .out file associated
+with that test, since the presence of the file in the build directory
+(with a more recent timestamp) implies that the test has already been
+run. Alternatively, one could simply use 'make -k check' to run the
+entire testsuite without halting for errors and then inspect the
+output and the relevant .out files for errors.
+
+ENVIRONMENT SETUP:
+
+The glibc testsuite requires that the prefix under which you have
+configured your build to install (with configure --prefix) should have
+a valid sysroot. Some test cases require C++ support and others may
+require stack frame unwind support, both of which may be provided by
+external libraries and these should be available from within the
+prefix. This should be automatically available if you configure your
+sources with --prefix=/usr but for all other prefixes (including the
+default /usr/local), additional setup is necessary.
+
+In the prefix that you configure your sources for, create a
+<prefix>/etc/ld.so.conf and write in it paths that contain the C++
+support libraries and the unwind support libraries. On Linux with gcc
+as your compiler, these would be libstdc++.so and libgcc_s.so
+respectively. So for a 64-bit Fedora installation, an ld.so.conf ought
+to contain:
+
+------------------
+/lib64
+/usr/lib64
+------------------
+
+Now run ldconfig as follows:
+
+ldconfig -f <prefix>/etc/ld.so.conf -C <prefix>/etc/ld.so.cache
+
+Now you should be ready to run the testsuite.
+
+Another alternative to this is to simply preload the required
+libraries. This can be done by exporting the LD_PRELOAD environment
+variable with the full library path name.
\ No newline at end of file
--
1.7.7.6