On Thu, 13 Feb 2014, Steve Ellcey wrote: > While testing the C++ profiling tests in g++.dg/bprob and using the > qemu simulator we discovered that these tests were passing when we ran > the testsuite with no extra options but that if we specified some options > on the testsuite run then the tests would fail with this message in the > c++.log file: > > rsh: Could not resolve hostname multi-sim/-EL: Name or service not known
That means your board file is buggy. If rsh is not the right way to access your target system, you need to implement the board file methods in some way other than rsh (possibly some operations should be no-ops, or do something directly on the build system, if you have a shared filesystem). > So while it seems weird that 'host' is the proper replacement for 'target' > as the machine where the executable is run, this seems to be the right fix It's certainly not the proper replacement. If a file is on the target, use target for deletion / manipulation; if it's on the host, use host for deletion / manipulation; on build, use build; in multiple places, run the deletion operation once per system with the file; to copy from target to the system (build) running DejaGnu, use remote_upload specifying target; to copy from host to build, use remote_upload specifying host; to copy from build to host or target, use remote_download specifying host or target as appropriate. To determine whether anything should be changed in a GCC .exp file, reason about which of the three systems (build, host, target) a file is on, or is needed on, at each point, rather than looking at what does or does not work with a buggy board file. -- Joseph S. Myers jos...@codesourcery.com
