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 Mon, Apr 2, 2012 at 10:04 AM, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
> On Mon, 2 Apr 2012 09:00:38 -0400
> "Carlos O'Donell" <carlos@systemhalted.org> wrote:
>> These failures are because you used --prefix but didn't provide a
>> correctly built sysroot in --prefix.
>>
>> I'm strongly against querying the compiler and adding whatever paths
>> it used to our library search list. Why? It complicates testing by
>> providing poor separation of the test framework from the natively
>> installed libraries. This becomes even more important when
>> cross-compiling and cross-testing.
>
> I don't think the requirement of having a sysroot within whatever
> prefix glibc is going to be installed is feasible, more so because it
> is necessary *just* for running the testsuite.

(a) Workaround.

Your workaround is to do the following:
- Configure with --prefix=/usr
- Install with `make install_root="/path/to/install" install`

(b) Talking about search paths and sysroots.

Would it be better if we added a option to glibc to tell it what
specific sysroot to use for testing?

Currently --prefix is being used for two things:

* Look here for a sysroot to use with your testing.

* Install to this location (which can be overriden at install time via
`make INSTALL=/path'?).

I can understand that this is confusing and not well documented.

Keep in mind that the idea is that you test your newly built glibc
with a potentially new set of libraries in the sysroot and eventually
pivot your root to the new location (which is one of the safe ways to
install a new C library).

> There is no real difference (on the 'separation from native libraries'
> front) between appending library search paths from the compiler to test
> case search paths, and working with a prefix that is a pre-built sysroot
> because the search order is what matters in the end and both cases
> have the same search order.

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.

To summarize:

(a) You configure with --prefix, and thus your only trusted directory
is the prefix.

(b) You run all tests with --library-path pointing at the prefix.

You now have an isolated testing system that doesn't look at any
libraries outside of the prefix.

Cheers,
Carlos.


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