if the test system is run locally (unix.exp) then
LD_LIBRARY_PATH set during compilation and linking.

this affects the dynamic linking of gcc and ld,
not just the linking and execution of the test binary.

normally this is not a problem because gcc does not depend
on target libs that can be confused with host libraries
(other than the libc), but plugins do.

so glibc to musl cross compiler plugin tests fail.
(i think other cross compilers that can be tested without
remote target board setup would also fail.)

gcc depends on host libc and the plugin.so depends on host
libc, libgcc_s and libstdc++, but the dynamic linker finds
the target libs first. (musl libc.so and glibc .so happen
to have different name so plain gcc uses the right libc,
but loading the plugin deps fail which depend on libc.so
instead of libc.so.6.)

i think only LD_RUN_PATH should be set for compilation
and linking.


example failures when running 
make check-gcc RUNTESTFLAGS=plugin.exp

FAIL: gcc.dg/plugin/self-assign-test-1.c -fplugin=./selfassign.so (test for excess errors)
Excess errors:
cc1: error: cannot load plugin ./selfassign.so
   /usr/lib/x86_64-linux-gnu/libc.so: invalid ELF header
FAIL: gcc.dg/plugin/ggcplug-test-1.c -fplugin=./ggcplug.so (test for excess errors)
Excess errors:
cc1: error: cannot load plugin ./ggcplug.so
   /usr/lib/x86_64-linux-gnu/libc.so: invalid ELF header