Re: FAIL: elf/tst-dlopen-aout?

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Apr 11, 2014 at 9:34 AM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> On Thu, Apr 10, 2014 at 5:04 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>> Paul,
>>
>> I'm seeing elf/tst-dopen-aout fail on x86-64, any idea why
>> that might be?
>
> Yes, this has been pointed out:
> https://sourceware.org/ml/libc-alpha/2014-04/msg00122.html
>
>> The initial dlopen succeeds despite the fact that it should
>> not. I'm not using --enable-hardcoded-path-in-tests.
>>
>> Joseph also noted the same failure here 9 days ago:
>> https://sourceware.org/ml/libc-alpha/2014-04/msg00012.html
>>
>> Also note that it would be nice if this test was disabled
>> if glibc was configured with --enable-hardcoded-path-in-tests.
>
> I'll send a patch to do that later today.
>
> I have an idea for a better fix: make the test actually work
> regardless of --enable-hardcoded-path-in-tests.
>
> That requires that I build a separate b.out, and try to dlopen it from
> tst-dlopen-aout. Unfortunately, I completely failed to understand the
> Makefile machinery to have a test that depends on another binary.
>
>> That shouldn't be too hard to do given that the --enable*'s
>> set a variable you can use to add or not add the test.
>>
>> However, first things, first, any idea what's wrong with the
>> test?
>
> There is nothing particularly wrong with it. As noted in the PR,
> running "ld.so ./a.out" uses a different code path, and doesn't expose
> the original bug. In writing the test, I wanted to make sure that we
> are in fact testing the failing code path, and without
> --enable-hardcoded-path-in-tests we are (currently) not.
>
>

If you can't find a way to test it without --enable-hardcoded-path-in-tests.
you can enable if by

ifeq ($(build-hardcoded-path-in-tests),yes)
endif

-- 
H.J.