This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Chroot testsuite
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Ryan Arnold <ryan dot arnold at linaro dot org>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Carlos O'Donell <carlos at redhat dot com>, 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 02:01:44 +0100
- Subject: Re: Chroot testsuite
- Authentication-results: sourceware.org; auth=none
- References: <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, Jan 15, 2014 at 06:22:40PM -0600, Ryan Arnold wrote:
> On Mon, Jan 13, 2014 at 8:12 PM, Joseph S. Myers
> <joseph@codesourcery.com> wrote:
> >
> >> >> > I would not be adverse to the normal glibc testsuite moving to installing
> >> >> > files in a staging directory within the build tree using install_root,
> >> >> > then running tests the same way they would be run with a previously built
> >> >> > and installed glibc, provided this does not require any extra software or
> >> >> > privileges for chroot.
> >> >>
> >> >> I think we've sorted out that this is possible to do this for existing
> >> >> tests that aren't meant to be integration tests that presume they're
> >> >> executing in the specified prefix.
> >> >
> >> > Note however there might still be concerns about how different ways of
> >> > testing exercise different code paths - see the discussion from when
> >> > --enable-hardcoded-path-in-tests was added, that resulted in it being a
> >> > non-default configure option rather than the only way to run tests. (An
> >> > actual chroot would of course test paths through the dynamic linker that
> >> > are closer to how people normally use glibc than either of the existing
> >> > approaches, or GLIBC_SYSROOT, is.)
> >>
> >> So are these integration tests that are maintained outside of glibc,
> >> or glibc tests that presumes an ABI compatible chroot is setup
> >> (somewhere--native or remote)?
> >
> > I don't understand your question. I'm talking about how normal, existing
> > glibc tests are run, or might be run in future.
>
> 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'm very interested in those sorts of tests. If glibc isn't the
> appropriate place for them I'll create them a framework that's more
> closely related to my build environment, but they probably won't be
> nearly as portable.
>
How big should chroot be? A closest you can get to real usage is by
running real programs. One alternative for integration tests would be use
phoronix test suite, a downside would be that you need to install lot of
dependencies.