The suffix "defined/undefined" in the ld test pr19719 name specifies
whether weak fun() is defined or undefined is mixed up.
The test builds an executable and a shared library. The latter in two
flavors, one with weak fun() defined (libpr19719a.so, "defined") and
one without weak fun() defined (libpr19719b.so, "undefined").
The first "Run $exe fun [...]" invocation uses libpr19719b.so as
libpr19719.so, which is build from dummy.c, which does not define fun.
Thus fun is undefined during this test run.
The second "Run $exe fun [...]" invocation uses libpr19719a.so as
libpr19719.so, which is build from pr19719d.c, which does define fun.
Thus fun is defined during this test run.
Correct the test naming mix-up accordingly.
ld/testsuite/
* ld-elf/shared.exp (mix_pic_and_non_pic): Correct test naming
mix-up of when weak fun is un-/defined.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
run_ld_link_exec_tests [list \
[list \
- "Run $exe fun defined" \
+ "Run $exe fun undefined" \
"-Wl,--no-as-needed,-rpath,tmpdir $ldflags tmpdir/libpr19719b.o tmpdir/libpr19719.so" \
"" \
{ pr19719a.c pr19719c.c } \
}
if ![isnative] {
- unsupported "Run $exe fun undefined"
+ unsupported "Run $exe fun defined"
return
}
set exec_output [run_host_cmd "tmpdir/$exe" ""]
if {![string match "PASS\n" $exec_output]} {
- fail "Run $exe fun undefined"
+ fail "Run $exe fun defined"
} else {
- pass "Run $exe fun undefined"
+ pass "Run $exe fun defined"
}
}