Re: Chroot testsuite

[Ryan Arnold <ryan dot arnold at linaro dot org>]

On Mon, Jan 13, 2014 at 8:12 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
>
> "make install" is supposed to convert from the source-tree and build-tree
> locations of files that end up in a glibc installation, to the locations
> of those files in an installation, and to copy the files accordingly.  I
> don't think it makes sense to hook it in any way.  Copying an installation
> tree from one system to another should be a completely separate step.

My suggestion for a post install hook was so that the process of
copying the files to the remote system, if desired, could be initiated
directly via the make install stage.  The same thing can be
accomplished with a script which does the copying after the entire
install stage is complete.

>
> 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?

>
> 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?

make install install_root=<build-dir>/install
make install_tests install_root=<build-dir>/install-tests

At which point one would run some script to recursively copy the
entirety of the build-dir (including install-tests/ and install/
directory to some remote machine).

>> If install_root isn't present in this case, what's the default
>> behavior?  I suppose the host tests are installed into some staging
>> directory and then executed, as dynamically linked, against the system
>> libraries.  Is that useful?
>
> It does not make sense to link (static-linker) tests with new libc and run
> them with old libc.  It may make sense in principle to run a new libc's
> testsuite with old libc, but then tests should be compiled with old libc's
> headers and linked with old libc.

In principle this would be a useful feature for testing compat_symbol
code paths.

> I don't understand your host_check concept, but while an externally
> specified install_root may be useful I'd assume the default would be
> installing into a standard location within the build tree.

I should have referred to them as tests run against the installed
libraries rather than as host tests.

The point in separating these (via a separate invocation) from the
builddir tests is that a developer might not want to install the
builddir on a remote machine, which means they won't want to run the
builddir tests on the remote machine.

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?

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

>
>> Do you recall what the concerns with providing GLIBC_SYSROOT were?  I
>> imagine the ease of bug reproducibility goes down for OS distributors
>> because they'll have to have additional verification that
>> GLIBC_SYSROOT is correctly set.
>
> See Roland's comments in the previous discussions, since he was the one
> raising concerns.

For reference, here's the discussion:

https://sourceware.org/ml/libc-alpha/2012-10/msg00313.html

There's a lot of stuff in there that I need to digest.

Ryan S. Arnold