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

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 8 Feb 2018, DJ Delorie wrote:

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

Not that I know of.  There's cross-rpcgen - which comes with a comment 
pointing to <https://sourceware.org/bugzilla/show_bug.cgi?id=14087> 
because of objections to using native-compile to implement that, but 
really the reason that issue is not fixed is that in general we don't 
*want* to build native programs (and we've been moving away from 
differences between native and cross compiles as far as possible).

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

I wasn't suggesting parsing linker scripts - rather, just copying the full 
set of libgcc_s.so* and libstdc++.so* files found alongside the output of 
-print-file-name.

That's a good idea *anyway* even in the absence of container testing.  
People testing with a compiler that doesn't correspond with installed 
libgcc_s / libstdc++ keep running into the need to copy those libraries 
into the glibc build directory before testing to avoid many tests failing 
(e.g. the RISC-V people ran into this).  The glibc build system ought to 
be able to find the required libgcc_s and libstdc++ and copy them into the 
build directory for testing so that you don't need to do so manually.

-- 
Joseph S. Myers
joseph@codesourcery.com