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 Tue, 3 Apr 2012 15:49:46 +0000 (UTC)
"Joseph S. Myers" <joseph@codesourcery.com> wrote:
> 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,
In that case we also need a switch in the linker to disable lookups in
ld.so.cache.
> 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.
How about if we run `built/ld.so --list <built-file>` to find
dependencies (allowing the indiscretion of having a fallback into
system libraries), and then use that information to symlink the extra
libraries into, say, $(builddir)/tests/lib/? That way the actual test
runs will be completely isolated, especially if we disable ld.so.cache
lookups in the dynamic linker.
--
Siddhesh