Re: [PATCH] Link dynamic tests with newly built glibc

[Roland McGrath <roland at hack dot frob dot com>]

The subject line is quite misleading.  We already do link test binaries
with the newly-built libc.  What you're talking about is linking the test
binaries such that they use the newly-built libc implicitly when run.

There is no one right answer.

The status quo has the nice property that you can just take a test binary
and run it against an installed libc manually, which people actually do
fairly often (including manual versions of cross-testing).  I certainly
want us to support cross-testing in a first-class way as soon as we can
manage to do it cleanly.

The closest you can get to running tests like normal user programs are run
is to populate a chroot and run there.  (Even that is not quite sufficient
if you want to test on a different kernel version than what you're running
on the build machine.)

The second closest is to bake a non-installed location into PT_INTERP
values.  But using RPATH exercises substantially different code paths in
the dynamic linker, really closer to what we do today with --library-path
than to the normal user scenario.

I am not at all sanguine about having a production dynamic linker pay
attention to a magic environment variable like GLIBC_SYSROOT.  I'd be more
inclined to link an almost-normal ld.so specifically for testing.  It would
differ only in baking in a different path using the absolute names of build
directories rather than ${libdir} et al, and a different cache file name.
Then the PT_INTERP of test binaries would be /build/dir/test-ld.so instead
of either the normal value or the name in the build directory of the ld.so
that will really be installed.

Another useful testing scenario would be actually not to link test binaries
with the newly-built libc.  That is, replicate the actual scenario of
running pre-existing binaries with a new libc installed, by having tests
built against an older libc.  This is more or less the only way we'll ever
manage to test compat_symbol code, among other things.

There is no way to get the behavior HJ wants without regressing on some of
the other cases in which test binaries as we build them today can be used
today.  So I have a high-level objection to the change, unless it's
optional under a makefile variable or configure switch.

What I really want to see is an overall plan to support all these different
testing scenarios, and also get to good results reporting that makes
monitoring regressions easy.  I also think we should move most of the
test-skeleton.c logic out to a wrapper program so we can more easily run
tests in scenarios (limited emulators, or non-Unix ports) where we can't
assume each test binary itself can fork.  That would need to be done in a
way wherein the details (timeouts, rlimits, etc.) that today tests tweak
with #define's before including test-skeleton.c can be communicated to the
test wrapper in some different fashion but still one where the information
is kept adequately close to the test's source.

Is someone collecting desires, ideas, and issues about the test suite
somewhere on the wiki?


Thanks,
Roland