Cross-compiling from "one Linux/GNU" to another, different
arches. In my case, from x86_64-unknown-linux-gnu to
crisv32-axis-linux-gnu. Replace with arm, mips, ppc or yourarch
as you please; you should see the same thing. When you've
eventually added the required telnet_exec support needed due to
the lack of rsh support on your target ("only" telnet and ftp),
and you get the files over to the target and chmod +x:ed, you'll
get (wrapped):
/tmp/20000112-1.x0.23789: error while loading shared libraries:
libgcc_s.so.1: cannot load shared object file: No such file or directory^M
Looking closer, I don't see anything in the gcc testsuite files
dealing with putting libgcc_s.so.1 on the target. It does set
LD_LIBRARY_PATH, except for is_remote targets where it returns
early, after the terse comment
# Setting the ld library path causes trouble when testing cross-compilers.
which is presumably because for the *compiler* it'd cause
problems, but for the *testcase*, it's certainly needed for
targets with dynamic linking. I'd rather not do the equivalent of
set_board_info ldflags "-static"
because that'd remove most of the value of this setup; I already
do that in a simulator setup.
Is it as simple as nobody having tested cross-gcc setups for
targets with dynamic linking, or are they incorrectly using the
wrong (the installed, not the newly compiled) libgcc_s.so.1?
Or how did you do it? NFS mounts on target and
"env LD_LIBRARY_PATH=... make check"?
brgds, H-P
