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 test programs


On Tue, Apr 3, 2012 at 1:34 AM, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
>> This doesn't make sense to me, could you please clarify and include
>> an exmaple?
>>
>> If you build with --prefix, then the *only* trusted directory is the
>> prefix and it's an absolute path. Therefore running with a
>> non-standard --prefix, and using --library-path only within the prefix
>> isolates the testing from *any* system libraries. Which is the type of
>> isolation you want for runtime library testing.
>>
>
> The missing link here is the ld.so.cache. With the current
> implementation, a test case is executed as:
>
> BUNCH_OF_ENV_VARIABLES /path/to/my/ld.so \
> --library-path=MY:BUILT:LIBS \
> testcase {test case args} > testcase.out
>
> My suggestion is:
>
> BUNCH_OF_ENV_VARIABLES /path/to/my/ld.so \
> --library-path=MY:BUILT:LIBS:gcc:libs \
> testcase {test case args} > testcase.out
>
> Assuming that we built with --prefix=/usr, in the first case, the
> library search sequence is:

The addition of ":gcc:libs" worries me. It's like throwing in the
kitchen sink, you may not have control over what goes into those
directories and that may affect testing.

> 1) Look in built libraries directory
> 2) Look up {prefix}/etc/ld.so.cache

No, #2 never happens, when using --library-path the dynamic linker
skips parsing the cache IIRC. I've never looked closely this code but
I'm pretty sure that's what happens.

> In the second case, the library search sequence is:
>
> 1) Look in build libraries directory
> 2) Look in gcc search paths
> 3) Look in {prefix}/etc/ld.so.cache

Remove #3 and I think that's right.

> In case 1, we are completely isolated from native libraries as long as
> we're in (1). Once we don't find the library in our built libraries
> directory, we ?look up /etc/ld.so.cache, which was generated by the
> natively installed ldconfig and is hence subject to the native setup.

No, in the testsuite we never end up using /etc/ld.so.cache because we
use --library-path.

> In case 2, we are again isolated from native libraries as long as we're
> in (1). If we don't find the libraries in (1), we let the compiler tell
> us what search path it used to find the libraries it linked into our
> test case. If even that doesn't work, we use {prefix}/etc/ld.so.cache
> to see if the ldconfig that *we* built generated a cache that had this
> library. But at no stage do we use the ld.so.cache that was generated
> by the ldconfig that is natively installed.

Correct, the testing doesn't use ld.so.cache ever.

>> (a) You configure with --prefix, and thus your only trusted directory
>> is the prefix.
>
> which, with /usr, is the entire system and hence the entire point of
> isolation is lost.

It is, but that's the default configuration.

Your original problem statment is "My testsuite fails."

The problem is: "You specified a prefix, which requires a sysroot,
that you didn't setup."

Your counter argument is: "It should just work."

The counter argument to that is: "It does, don't set prefix."

I think it's the *definition* of what --prefix means that is cause the problem.

In every other project --prefix simply means "install here."

In glibc it means more than that and has implications on the testing framework.

Would it beneficial to add another option to deal with just the
testing framework?

Cheers,
Carlos.


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