[FFmpeg-trac] #1676(build system:new): Compile fails if --progs-suffix= is set in ./configure

[FFmpeg]

#1676: Compile fails if --progs-suffix= is set in ./configure
-------------------------------------+-------------------------------------
             Reporter:  nichot20     |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:  build        |                  Version:  git-
  system                             |  master
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Summary of the bug:

 Commit 11a1033c9fca introduced separated out code from ffmpeg.o into
 ffmpeg_opt.o and ffmpeg_filter.o.

 With this arrangement if --progs-suffix="something" is used during the
 ./configure stage, PROGSSUF in config.mak is set to this value.

 Under this circumstance ffmpeg_opt.o and ffmpeg_filter.o are not set as
 targets in the make system (according to make -p -n), so when an attempt
 is made to link to them the make fails.

 How to reproduce:
 {{{
 ./configure \
 --enable-static --disable-shared \
 --prefix=$SYSROOT/usr/local \
 --libdir=$SYSROOT/usr/local/lib64 \
 --samples="../fate-suite/" \
  \
 --extra-cflags="-static -I$SYSROOT/usr/local/include" \
 --extra-ldflags="-static -L$SYSROOT/usr/local/lib64" \
 --progs-suffix="_bisect"
 make
 [...]
 AR      libavutil/libavutil.a
 CC      ffmpeg.o
 CC      cmdutils.o
 LD      ffmpeg_bisect_g
 gcc: error: ffmpeg_opt.o: No such file or directory
 gcc: error: ffmpeg_filter.o: No such file or directory
 make: *** [ffmpeg_bisect_g] Error 1
 }}}

 compared to a working build with --progs-suffix="" which gives
 {{{
 AR      libavutil/libavutil.a
 CC      ffmpeg.o
 CC      cmdutils.o
 CC      ffmpeg_opt.o
 CC      ffmpeg_filter.o
 LD      ffmpeg_g
 }}}

 I have looked at the main Makefile around lines 93-102, which seems to be
 the meat of it but cannot see why this behavior is affected by the setting
 of PROGSSUF. Perhaps someone with a better understanding of the make
 system can spot it...

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1676>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker