Re: Chroot testsuite

[Ryan Arnold <ryan dot arnold at linaro dot org>]

On Wed, Jan 15, 2014 at 7:07 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Wed, 15 Jan 2014, Ryan Arnold wrote:
>
>> > That is, for build-tree testing to start
>> > by running "make install install_root=<build-dir>/install-tests"
>>
>> I'm not sure I understand correctly.. did you mean build-tree testing?
>
> Yes.  So that instead of
>
> (a) "make install" knows where libraries are in the build tree and where
> to install them, and
>
> (b) "make check" knows where libraries are in the build tree, in order to
> pass --library-path options to ld.so,
>
> you have just
>
> (c) "make install" knows where libraries are in the build tree and where
> to install them, and
>
> (d) "make check", in the default case, installs and then uses
> --library-path
> <build-dir>/install-tests/lib:<build-dir>/install-tests/usr/lib and
> doesn't need to know the details of the directories from which libraries
> came.

Ok, this is now this is clear to me.

>> > I'd be quite happy for "make install" to be the *only* thing that needs to
>> > know the aforementioned mapping.  That is, for build-tree testing to start
>> > by running "make install install_root=<build-dir>/install-tests"
>>
>> Shouldn't we use an alternate install rule so that these tests aren't
>> always built for every run of make install, but rather only when
>> desired?
>
> I'm not thinking of "make install" installing any tests - rather,
> installing the usual libraries, data files, etc. that get used by tests.
>
> (I do want a separate target meaning "install build-tree files needed by
> tests but not otherwise installed" - for example, linkobj/libc.so used to
> link RPC tests.)

Ok.

>
>> When make install is run it absolutely makes sense to install the
>> install tests in the builddir by default, but it you don't have the
>> builddir installed remotely, where do you install the tests?
>
> builddir files from the build that are needed for testing should be
> installable by some special makefile target.
>
> I don't think of tests themselves as needing installing - just files used
> to build or run tests.

In the absence of a shared file-system, when executing the tests
remotely, I guess we can pipe the binary over ssh for remote execution
rather than copying it over before hand, e.g.,

cat testcase | ssh -e none ryanarn@remote 'cat - > testcase; chmod +x
testcase; <build-dir>/install-tests/lib/ld.so.1
--library_path=<build-dir>/install-tests/lib:<build-dir>/install-tests/usr/lib./testcase
'

But preferably make check, as you've described it in (d) above, would
be able to 'install' the binary remotely.  Where does it install the
binaries?  In <build-dir>/install-tests directly?

>
>> I'm referring to your statement: "An actual chroot would of course
>> tests paths through the dynamic linker that are closer to how people
>> normally use glibc".  So my question is how do we accommodate (in
>> glibc) tests for exactly those paths?
>
> I'd imagine new makefile variables set when testing to indicate to test in
> a chroot (which might also enable some tests not supported when testing in
> other ways) - with the way in which any parts of the chroot, beyond
> glibc's install_root, are set up, being outside the scope of glibc's
> makefile targets although there might be example helper scripts provided.

Out-of-scope for glibc proper, but directly relevant to full test
coverage, so we should continue to discuss helper scripts.

Ryan S. Arnold