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 test programs
On Wed, Apr 4, 2012 at 2:55 AM, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
>> The libraries may not be in standard system directories. ?Suppose for
>> example you have GCC (built elsewhere, say) installed into
>> nonstandard directories with 32-bit libgcc_s and libstdc++ on an
>> otherwise purely 64-bit x86_64 system, and are using that GCC to
>> build 32-bit libc. ?The required shared libraries for testing exist,
>> and that GCC can find them, but ld.so --list won't find them.
>> Testing in this case still ought to work.
>>
>
> Hmm, this ought to be possible by adding the gcc search paths during
> this search and then symlinking the libraries into the build
> environment. Carlos, do you think this would be OK? With this the gcc
> search paths can be used to find the extra libraries and symlink those
> libraries into the build directory. The actual test runs will then be
> completely isolated.
It sounds like that should work and maintain isolation.
> I have a pretty straightforward patch that implements --inhibit-ldcache
> in the dynamic linker to tell the linker not to look at ld.so.cache. I
> will post it once I finish testing it. With this change and
> --library-path, we should ?be able to limit dso search to just the
> built libraries and symlinked libraries and paths built into rpath
> during test case compilation.
I think inhibiting ld.so.cache is a good idea for a test framework.
We want to maintain test isolation from the current system.
Cheers,
Carlos.