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
On Tue, Oct 9, 2012 at 8:59 AM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Tue, 9 Oct 2012, H.J. Lu wrote:
>
>> On Tue, Oct 9, 2012 at 8:07 AM, Joseph S. Myers <joseph@codesourcery.com> wrote:
>> > In various places this patch removes use of run-program-prefix, or
>> > replaces built-program-cmd by built-program-file.
>> >
>> > Having such abstractions used to run tests is still useful towards
>> > supporting cross testing - the default setting of the prefix used when
>> > running a test program can be empty, but it's still useful to have a
>> > variable used for running them which could have a nonempty setting in the
>> > cross-test case. I guess I'd rather see these places use e.g. new
>> > variables test-program-prefix and test-program-cmd (defaults empty and
>> > built-program-file), or something like that, as a basis for then adding
>> > more cross-test support.
>>
>> What do you mean by "cross testing"? Those tests can only be
>> run natively.
>
> I intend to contribute support for cross testing at some point - running
> tests on a separate system, of a different architecture, from that on
> which glibc was built. (The code is already in EGLIBC.)
>
> For cross testing, it's necessary to have an abstraction "run this newly
> built program on the host (rather than the build system)", and
> run-program-prefix and built-program-cmd, through being used in most
> places that run test programs newly built for the host, are a good place
> to hook in that abstraction.
>
> Those variables, however, combine the concept of "run a newly built
> program for the host" with that of "run a newly built program that has
> been built to use the standard dynamic linker path". The aim of your
> patch relates to this second concept: while programs such as localedef,
> built to be installed, still need to be run using the dynamic linker, test
> programs can be run without executing the dynamic linker specially to run
> them.
>
> Rather than removing both abstractions at once from various affected
> places, so the first abstraction then needs to be added back in all those
> places, it would seem better to make changes that only affect the second
> one. Instead of completely removing run-program-prefix when running
> testcases, use a variable with the semantics of "run a program that has
> been linked with a -dynamic-linker option pointing into the build tree".
> Likewise for built-program-cmd: the fact that you are running a command is
> still meaningfully different from a reference to the executable file being
> run for that command.
>
Thanks for explanation. Then, we need test-program-prefix and
test-program-cmd for both static and dynamic tests.
--
H.J.