This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Append system library paths to environment for testprograms
On Mon, 2 Apr 2012, Siddhesh Poyarekar wrote:
> Both approaches are vulnerable to the above failures. In fact, I don't
> think there is a way to separate the test framework from the native
> system beyond a point that we already do unless you either decide to
> manually copy over dependencies using some magic method (which I think
> will eventually involve getting search paths used during build) or
> statically link anything that is external (which will again involve
> getting search paths used during build).
I do not think that running a testcase should ever involve the newly built
glibc referring to anything from the configured prefix: not shared
libraries there, not ld.so.conf, not ld.so.cache, not locales, not
timezone data, etc.; the testsuite should be properly isolated from
whatever is previously installed. To the extent that this is not achieved
(where glibc cannot disable searching the configured prefix, or where
relevant environment variables are not set), it would be good for glibc to
handle environment variables to support such isolation. Perhaps a generic
GLIBC_SYSROOT variable would be good if the testsuite were made to install
the library into a sysroot in the build directory, to avoid the need for
many other variables. (Such a variable would mean that whenever glibc
would search some configured path, instead it searches that path with
$GLIBC_SYSROOT prepended.)
In turn, I think this does mean that testsuite setup needs to locate the
relevant shared libraries (libgcc_s, libstdc++) and copy / symlink them
somewhere they will be found in the testsuite run, so that the dynamic
linker does not need to search directories that may also contain other
unknown irrelevant files.
I do not think it's appropriate to recommend setting variables such as
LD_PRELOAD when running the testsuite; indeed, I think the testsuite
should detect if such variables that affect glibc's behaviour are set when
it is run, and either give an error and refuse to execute the tests, or
unset / override them, again so that the tests are run in a properly
isolated environment.
--
Joseph S. Myers
joseph@codesourcery.com