Re: Chroot testsuite

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Sat, 11 Jan 2014, Ryan Arnold wrote:

> > glibc testing should not assume any particular packages on the host; it
> > should work even if what you get from ssh is just a busybox shell (with no
> > privileges to run chroot).
> 
> So for the general case of builddir tests being turned into
> host/install tests (i.e., not integration tests), this means that
> glibc would copy the local install_root contents onto the remote
> machine where the tests will then be executed there by invoking the
> test via the dynamic linker <install_root>/elf/ld[64].so <testcase>?

Yes.  (Well, copying should be optional - it's not needed when you have a 
shared filesystem, but Brooks has requested support for testing without 
such a shared filesystem, which certainly makes sense as well.)

> > It should also not require that any OS
> > binaries are available that are compatible with the newly built glibc
> > rather than being linked with some other incompatible libc (consider, for
> > example, testing an x32 glibc when nothing other than the kernel supports
> > x32, or testing an ABI-changed glibc as part of bringing up a port).
> 
> Is this scenario always remote because it means we're testing in a VM
> or can the kernel now support executing more than one ABI?

It can be native.  The kernel has supported multiple ABIs for many years - 
I expect that most tests done for x86 glibc now are actually done on a 
64-bit kernel, and the system might or might not have installed any 32-bit 
compatibility library packages the distribution provides.

When testing for MIPS, I don't worry about whether the host system has 
libraries for a particular one of the three ABIs installed in its root 
filesystem - and actually I test both hard-float and soft-float on the 
same system (so six ABIs on a BE system and six on an LE system), and 
hard-float and soft-float ABIs for MIPS are incompatible but share the 
same SONAMEs.  So a chroot constructed with a mixture of newly built 
soft-float libraries, and previously built hard-float binaries from the 
distribution, isn't going to work - any binaries needed for the chroot 
tests, beyond those coming with glibc, would have to be built for the 
specific ABI under test.

> > 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.)

> > I've previously suggested a GLIBC_SYSROOT environment variable for use in
> > testing, that would allow more of the effects of chroot to be emulated
> > without needing any privileges or extra installed software, but there were
> > some concerns about having such a variable.
> 
> This would be a way around tests that presume they're executing in the
> specified prefix (such as ldconfig).  This would also solve other
> problems... such as Linux distributions that want to have experimental
> toolchains that don't have to have their binaries executed in chroots.

The generic problem of users running programs with a special version of 
glibc not installed in the root directory, and without files from the root 
directory getting used implicitly by glibc, is certainly a motivation for 
GLIBC_SYSROOT beyond the possible use in the glibc testsuite.

-- 
Joseph S. Myers
joseph@codesourcery.com