RFC [0/2] test-in-container

[DJ Delorie]

Joseph Myers <joseph@codesourcery.com> writes:
> Suppose /bin/sh uses a library whose system location is the same as the 
> location where the glibc-under-test would install something in the chroot.  
> (For example, say it uses /lib/libc.so.6 and the glibc-under-test would 
> also install that file.)  Do you keep the two copies separate - keep sh's 
> libraries somewhere else in the chroot so the new glibc's don't overwrite 
> them?

The install is done in order such that the newly built files override
any files copied from the system.

> Even for native testing, you can't assume that the two have the 
> same ABI - consider various cases where hard-float and soft-float have 
> different ABIs but use the same library paths, for example.

The tests are listed separately (tests-container vs tests) so we would
have to skip containerized tests when they can't run that way.
Mis-matched ABIs is just one step along the path to incompatble; I
haven't even tried to make cross-compiled-container-testing work.

> What do in-container tests actually require /bin/sh to be able to do?  Is 
> it more than just e.g. "split a command on spaces and execute it"?  (I'm 
> wondering if a trivial /bin/sh implementation like that would suffice 
> inside the chroot.)

Mostly, it's for popen() testing, and related functions, which are
already "problematic" as per your description above, but so far seem to
be OK.