This is the mail archive of the
mailing list for the glibc project.
Re: Support cross-testing (version 2)
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Tue, 23 Oct 2012 14:11:59 -0700 (PDT)
- Subject: Re: Support cross-testing (version 2)
- References: <Pine.LNX.firstname.lastname@example.org>
It shouldn't be unconditional like that. As written, 'make check' in
cross-build will now fail all over the place trying to run host binaries on
the build system. When cross-compiling and not doing anything special,
'make check' ought to run the tests that can be run without a host system
and not try to run other tests at all. So things like check-abi and
check-localplt are unconditional. Everything that requires running built
test programs should test something like $(run-built-tests). Then we can
figure out the exact logic to set that to yes or no. To start with, it can
just be set to the inverse of cross-compiling. That's a straightforward
After that, cross-test-wrapper is a poor name. It's really just an
additional prefix for running test programs and doesn't intrinsically have
anything to do with cross-ness. Unfortunately we're already using the most
obvious name, run-program-prefix, for an internal variable.
It's also not really right to use the same thing for running built binaries
directly and for running "env ...". If it's an emulator, then it can only
run the host binaries, not some "env" binary that doesn't necessarily exist.
Using it for "sh -c ..." is even worse.
Getting rid of the kludgey overloading of *-ENV variables is worthwhile.
It should also be separable from the rest of this. Given all the bad
issues of dealing with shells and so forth, probably the right thing to do
is make tst-oddstacklimit.c be a test that calls setrlimit and then execs
itself with an argument that says to really run the test code the second time.
Or, perhaps just execs tst-basic1 instead.