This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Link dynamic tests with newly built glibc
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 11 Oct 2012 12:45:20 +0000
- Subject: Re: [PATCH] Link dynamic tests with newly built glibc
- References: <20121009124954.GA30448@gmail.com> <20121011000517.F33FA2C06C@topped-with-meat.com>
On Wed, 10 Oct 2012, Roland McGrath wrote:
> 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
I don't think such a variable is really any different in principle from
those such as LD_LIBRARY_PATH, GCONV_PATH and LOCPATH - but it certainly
simplifies the use of a glibc installation not installed directly into /,
as otherwise you have lots of variables to set (and some standard paths
glibc searches have no corresponding environment variable at all), and
there are uses of that beyond just running tests.
> inclined to link an almost-normal ld.so specifically for testing. It would
One use case for testing I'd like supported is testing a previously built
glibc, not necessarily installed in /, without needing the build tree in
which it was built. Special variants of ld.so or libc.so that are used in
testing but not installed are bad for that. (For things such as
linkobj/libc.so, used in sunrpc tests, maybe there should be an option to
install them somewhere for later use in testing. For tests such as
tst-xmmymm.sh or check-local-headers.sh that are fundamentally based
around examining the build tree rather than running things built with the
installed library, maybe they should actually be part of the build process
rather than part of a testsuite run.)
--
Joseph S. Myers
joseph@codesourcery.com