Is anyone testing for a (cross-) target (board) with dynlinking?

2 msg	GCC Test Question
2 msg	compilation flow
8 msg	Problem with libiberty's hash tables
1 msg	Can't reproduce PR34800/PR28706 with gcc 4.3 (a...
2 msg	Possible ABI issue: PR33823
2 msg	future MELT (formerly Basilys) branch
10 msg	lto
1 msg	[offtopic, nontechnical] GCC in Europe thru ITEA2
2 msg	GIMPLE: obtaining informations about variables
3 msg	gcc 4.2.3 bootstrap seems to be broken on AIX...
41 msg	GCC 4.3.0 Status Report (2008-02-14)
1 msg	gcc-4.2-20080213 is now available
12 msg	When is RBX used for base pointer?
1 msg	GNAT/RTEMS ACATS Scripts
5 msg	ICE in delete_output_reload
5 msg	GCC ssa and alias info
3 msg	LLVM 2.2
1 msg	This company is being noticed

Is anyone testing for a (cross-) target (board)...
\ Hans-Peter Nilsson (12 Feb 2008)
. \ Nathan Froyd (12 Feb 2008)
. . \ Hans-Peter Nilsson (12 Feb 2008)
. . . \ Nathan Froyd (12 Feb 2008)
. . . \ Ian Lance Taylor (12 Feb 2008)
. . . . \ Hans-Peter Nilsson (12 Feb 2008)
. . . . . \ Robin Getz (17 Feb 2008)
. . . \ Daniel Jacobowitz (12 Feb 2008)
. . . . \ Hans-Peter Nilsson (12 Feb 2008)
. . . . . \ Daniel Jacobowitz (12 Feb 2008)
. . . . . . \ Ian Lance Taylor (12 Feb 2008)
. . . . . . \ Hans-Peter Nilsson (13 Feb 2008)
. \ David Daney (12 Feb 2008)

1 msg	gcc-4.1-20080211 is now available

Subject:	Is anyone testing for a (cross-) target (board) with dynlinking?
Group:	Gcc
From:	Hans-Peter Nilsson
Date:	12 Feb 2008

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