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

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 8 Feb 2018, DJ Delorie wrote:

> This system is also incompatible with ssh-based cross-testing, if only
> because test-container.c is compiled with the native tools and I
> didn't want to make this patch more complex than needed.

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.  But we've reduced the set of tests not 
run in cross-testing down to *only* the very small number of assertions 
within the conform/ tests that require executing a test program (to test 
properties of a symbol that's not a compile-time constant - "symbol" and 
"macro-str" assertions in config/data/* that say something about a value 
rather than just that a symbol exists) rather than being testable at 
compile time.  We should avoid regressing there - meaning that all new 
tests should always support cross testing via wrappers.

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.

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

For libraries used by links-dso-program there are extra complications.  A 
native installed ldd will try examining a program using an installed 
dynamic linker.  But (a) an installed dynamic linker may not be able to 
handle the program linked with new glibc, new binutils etc., and (b) there 
may be no installed dynamic linker in a system directory for the ABI under 
test at all.  (Consider e.g. the case of native testing of x32 glibc on an 
x86_64 system, where you're building with a non-system GCC and there is no 
/libx32/ld-linux-x32.so.2 installed on the system, so system ldd cannot 
work for examining that program.  So even in the case of testing natively, 
no wrapper involved, you can't safely use installed ldd on a newly built 
program.)  I think you need to run with the *new* dynamic linker (with 
appropriate options) in order to identify the locations of libgcc_s and 
libstdc++ (and I suppose maybe libunwind in the ia64 case) to copy.  (Or 
use -print-file-name=libgcc_s.so etc. and then go from the .so file, which 
may be a linker script, to the actual shared libraries alongside it.)

-- 
Joseph S. Myers
joseph@codesourcery.com