This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]