Chroot testsuite

[Ondřej Bílka]

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.