target path not taken into account

[michael.kostylev]

Summary of the bug:
When running FATE some output files may be created on a remote side using a relative path (as usual, with an IO error). The issue affects hundreds of tests.

How to reproduce:
Configure and build for remote testing, run an affected test:

% make V=2 fate-ws_snd
TEST    ws_snd
/home/mik/src/ffmpeg/src/tests/fate-run.sh fate-ws_snd "/home/mik/src/ffmpeg/fate-suite" "ssh localhost " "/mnt/nfs/bb/home/mik/src/ffmpeg/x86_32-linux-gcc-musl-remote/build" 'md5 -i /home/mik/src/ffmpeg/fate-suite/vqa/ws_snd.vqa -f s16le' '' '' '' '1' '' '' '' '' '' '' '' '' '' ''
ssh localhost  /mnt/nfsbb//home/mik/src/ffmpeg/x86_32-linux-gcc-musl-remote/build/ffmpeg -nostdin -nostats -cpuflags all -hwaccel none -threads 1 -thread_type frame+slice -i /home/mik/src/ffmpeg/fate-suite/vqa/ws_snd.vqa -f s16le tests/data/fate/ws_snd.out
--- /home/mik/src/ffmpeg/src/tests/ref/fate/ws_snd      2018-11-11 23:01:19.813385323 +0300
+++ tests/data/fate/ws_snd      2018-11-14 14:36:22.778457365 +0300
@@ -1 +0,0 @@
-023317c7876aa5271f086f753d84561b
Test ws_snd failed. Look at tests/data/fate/ws_snd.err for details.
ffmpeg version N-92434-g2f888771cd Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 8 (Debian 8.2.0-9)
  configuration: --prefix=/home/mik/src/ffmpeg/x86_32-linux-gcc-musl-remote/install --samples=/home/mik/src/ffmpeg/fate-suite --enable-gpl --enable-memory-poisoning --enable-avresample --arch=x86 --cc=musl-gcc --target-exec='ssh localhost' --target-path=/mnt/nfs/bb/home/mik/src/ffmpeg/x86_32-linux-gcc-musl-remote/build --extra-ldflags=-static --disable-debug --disable-pic --enable-runtime-cpudetect
  libavutil      56. 23.101 / 56. 23.101
  libavcodec     58. 39.100 / 58. 39.100
  libavformat    58. 22.100 / 58. 22.100
  libavdevice    58.  6.100 / 58.  6.100
  libavfilter     7. 43.100 /  7. 43.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
  libpostproc    55.  4.100 / 55.  4.100
Input #0, wsvqa, from '/home/mik/src/ffmpeg/fate-suite/vqa/ws_snd.vqa':
  Duration: 00:00:17.60, start: 0.000000, bitrate: 45 kb/s
    Stream #0:0: Video: ws_vqa, pal8, 240x150, 10 fps, 10 tbr, 10 tbn, 10 tbc
    Stream #0:1: Audio: westwood_snd1, 22050 Hz, mono, u8
tests/data/fate/ws_snd.out: No such file or directory
md5sum: tests/data/fate/ws_snd.out: No such file or directory
make: *** [/home/mik/src/ffmpeg/src/tests/Makefile:228: fate-ws_snd] Error 1

tests/data/fate/ws_snd.out as an output file has no sense, it should be prefixed by the target path.

[michael.kostylev]

Just for comparison:
​http://fate.xffm.org/report.cgi?time=20181114072523&slot=x86_32-linux-gcc-musl
​http://fate.xffm.org/report.cgi?time=20181114074847&slot=x86_32-linux-gcc-musl-remote

[michael.kostylev]

A possible workaround is to use a script that would fix the cwd on a remote side. This is how FATE worked in the early days.

[Carl Eugen Hoyos]

Does this commit message help?
af39b8fec46b5557ff8b95921d9ad339c20c92cd

[Carl Eugen Hoyos]

Some random comments:
The aix targets (should) need --extra-cflags=-mminimal-toc, this is supposed to have no speed impact, please remove arch from as many tests as possible, it is only needed for cross-compilation, has no effect (and is misleading) for 32-bit compilation on x86-64 and if it had an effect ppc would be wrong for -maix64.
The valgrind targets need --disable-stripping to be useful.
Compilation on Solaris is currently broken: If you cannot replace /usr/xpg4/bin/sed, you have to replace the first sed -E in configure with /opt/csw/gnu/sed -E (this is ticket #7310).

Somebody else will have to comment on the Windows issues.

[Carl Eugen Hoyos]

I hadn't realized so far that the rv20-1239 failure on aix is identical to the rv20-1239 failure seen with some compilers on Linux ppc (like gcc-4.9 but not gcc-5.5 on 64bit ppc but gcc-5.5 and not gcc-4.9 on 32bit ppc)...

[michael.kostylev]

Does this commit message help?
af39b8fec46b5557ff8b95921d9ad339c20c92cd

The message is so useful that I would expect to read something like this in the documentation, if the path handling cannot be fixed in the code.

[Carl Eugen Hoyos]

The dnxhd issues on 32bit aix can be solved with --extra-ldflags='-Wl,-bmaxdata:0x80000000'