This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Chroot testsuite
- From: Ryan Arnold <ryan dot arnold at linaro dot org>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, OndÅej BÃlka <neleai at seznam dot cz>, Will Newton <will dot newton at linaro dot org>, GNU C Library <libc-alpha at sourceware dot org>, Robert Savoye <rob dot savoye at linaro dot org>, Matthew Gretton-Dann <matthew dot gretton-dann at linaro dot org>
- Date: Thu, 16 Jan 2014 10:54:39 -0600
- Subject: Re: Chroot testsuite
- Authentication-results: sourceware.org; auth=none
- References: <52A6732E dot 4030905 at redhat dot com> <CANu=DmgWNhyxq9vE37bvvD=PrDrfi0Y+eAMv0i2KZPxaEnEOxw at mail dot gmail dot com> <20131210111201 dot GA5309 at domone dot podge> <52A764F3 dot 60501 at redhat dot com> <CAJE4xBMs-Qz4J01Z7M4ebwA11MZ_Uf6vdbSJ-GyCuZHbWNCFjw at mail dot gmail dot com> <52B3C775 dot 4070503 at redhat dot com> <CAJE4xBOBfyPsXpW9JMmDd7D2uS-BkJ019+Lsrsxu0Ydg+XvVvw at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1401110109210 dot 16742 at digraph dot polyomino dot org dot uk> <CAJE4xBNKPXPhSWkCGsHm3j=k8pHDE+rjN-tjv82r3fX9WmH8gw at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1401120030510 dot 11301 at digraph dot polyomino dot org dot uk> <CAJE4xBPbDrKiGUmQ+pGtM+msdwc8OMJH0WLD2zREbZ=i_qko2w at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1401140201400 dot 29865 at digraph dot polyomino dot org dot uk> <CAJE4xBNw0v94GXwFf=+6CJP2oK=NqO5hWi4ZYzP3za73DDGQMA at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1401160058250 dot 27886 at digraph dot polyomino dot org dot uk>
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