Re: RFC [0/2] test-in-container

[DJ Delorie <dj at redhat dot com>]

Joseph Myers <joseph@codesourcery.com> writes:
> I haven't tried to figure out whether this patch achieves (a) compiling 
> these tests unconditionally, whether or not they can be run, (b) not 
> running these tests if run-built-tests = no and (c) even when 
> run-built-tests = yes, not running them when a wrapper is in use given 
> they won't work with a wrapper.

I expect a wide range of heated discussion about if/when/why/how special
tests should be run, and in the first iteration of my setup I was trying
to run *all* the tests in a container, so at least I've limited the
damage to only those tests that *require* a container (which, by
definition, there aren't any of yet).  And if a test requires a
container, it will be interesting to figure out how containerized
testing and wrapped/remote testing should or *could* work together, much
less the messy mechanics of actually doing it.

For cross-testing it's messier, because you'd have to find the right
runtime for the container from the target system, if it's available at
all.  We might just have to flag containerized tests as "don't run" in
those cases.

> Also, $(native-compile) should be considered obsolescent - it's used only 
> for two tests that ought to be merged into conformtest - rather than 
> having any new uses added.

Is there an example of something similar elsewhere in our Makefiles that
I could copy instead?

> I'd expect test-container.c to be compiled against the newly built libc as 
> usual, and run with the wrapper.  I'd expect a program compiled against 
> the newly built libc and run with the wrapper to achieve the effect of 
> "identify libraries /bin/sh needs and copy them".

Doable, although for convenience I run some system programs (like rm)
which would have to be internalized (like I did to avoid requiring
rsync).

> For libraries used by links-dso-program there are extra complications.

I thought of --print-file-name but I wanted to be a bit more clever (and
simple) about what was *needed* and let ld.so tell me.  The Makefile
fragment is already complicated enough just reading the ld.so output.
Adding "parse gcc and linker scripts" would be unmanageable.