This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Chroot testsuite
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Ryan Arnold <ryan dot arnold at linaro dot org>
- 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 01:07:48 +0000
- 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>
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.
> > 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.)
> 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.
> 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.
--
Joseph S. Myers
joseph@codesourcery.com