Am 04/08/2015 um 10:28 AM schrieb Denis Chertykov:
2015-04-07 15:34 GMT+03:00 Georg-Johann Lay <a...@gjlay.de>:
Am 04/06/2015 um 11:54 AM schrieb Sivanupandi, Pitchumani:
Hi Johann,
Did you try running g++ tests?
It seems xgcc is invoked to get multilibs (from gcc/testsuite/lib/g++.exp)
which failed to find specs file.
This is because libgloss.exp:get_multilibs (used from g++_init) runs xgcc
($compiler) without -B, i.e. without any prefix. Without prefix there is no
way to determine where the specs files are located.
Patching driver_self_specs to read a specs file by means of -specs= is,
well, not very common. I don't know any other target which does that.
As a work-around you can run the tests against the installed compiler.
Denis, what do you think? I could add yet another fixme to avr backend like
the following; that way there's no need to change dejagnu:
Johann
Index: config/avr/driver-avr.c
===================================================================
--- config/avr/driver-avr.c (revision 221602)
+++ config/avr/driver-avr.c (working copy)
@@ -80,6 +80,20 @@ avr_devicespecs_file (int argc, const ch
return X_NODEVLIB;
case 1:
+ if (0 == strcmp ("device-specs", argv[0]))
+ {
+ /* FIXME: This means "device-specs%s" from
avr.h:DRIVER_SELF_SPECS
+ has not been resolved to a path. That case can occur when the
+ c++ testsuite is run from the build directory. DejaGNU's
+ libgloss.exp:get_multilibs runs $compiler without -B, i.e.runs
+ xgcc without specifying a prefix. Without any prefix, there
is
+ no means to find out where the specs files might be located.
+ get_multilibs runs xgcc --print-multi-lib, hence we don't
+ actually need information form a specs file and may skip it
+ altogether. */
+ return X_NODEVLIB;
+ }
+
mmcu = AVR_MMCU_DEFAULT;
break;
I'm weak in dejagnu internals and c++ testsuite.
It looks like an acceptable solution.
Denis.
Pitchumani, does that patch work for you? If so I'd go ahead and apply it.
And what about the spaces problem as mentioned in
http://savannah.nongnu.org/bugs/?44574
http://lists.gnu.org/archive/html/avr-libc-dev/2015-03/msg00010.html
Art there plans to fix that?
Johann
