This is the mail archive of the
mailing list for the glibc project.
Re: RFC [0/2] test-in-container
- From: DJ Delorie <dj at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 08 Feb 2018 19:15:10 -0500
- Subject: Re: RFC [0/2] test-in-container
- Authentication-results: sourceware.org; auth=none
Joseph Myers <email@example.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
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