On 7/26/21 2:13 PM, Sandra Loosemore wrote:
On 7/26/21 3:45 AM, Tobias Burnus wrote:
[snip]
PS: Still, it would be nice if the proper multi-lib ISO*.h could be
found;
while it usually does not matter, it could do so in some cases.
I think I ought to fix this now instead of just sweeping it under the
rug. The suggestion you made previously to add
# Flags for finding libgfortran ISO*.h files.
if [info exists TOOL_OPTIONS] {
set specpath [get_multilibs ${TOOL_OPTIONS}]
} else {
set specpath [get_multilibs]
}
set options "-I $specpath/libgfortran/"
to the .exp files looks consistent with what I see elsewhere for adding
things to the include path, so I will give it a try and see how it works.
Unfortunately, I could not get this to work. For installed-tree
testing, this resulted in diagnostics about a nonexistent directory on
the include path. In my i686-pc-linux-gnu build I was having other
problems when I tried build-tree testing using
make check-gfortran RUNTESTFLAGS="--target-board=localhost/m64"
or similar variants of --target-board (it seemed to be ignoring all the
xfails?) so I did not think that could be the way people who normally
test in the build tree can be doing it. And when I tried a recipe like
make check-gfortran RUNTESTFLAGS="ts29113.exp --tool_opts='-m64'"
it found the ISO_Fortran_binding.h via the correct /64-specific path via
a -B option, same as for installed-tree testing.
Since the patch was already approved without additional hacks to include
file paths, I went ahead and pushed it as-is. If somebody can provide
me with an exact recipe for reproducing failures to find the include
file, I'll take another stab at it, but TBH this is far from my area of
expertise. :-(
BTW, I can't find any documentation for what get_multilibs is supposed
to do. It seems to be part of Dejagnu itself rather than the gcc test
support?
-Sandra