Builder ffmpeg-solaris10-sparc Build #12436

Results:

Failed shell_2 shell_3 shell_4 shell_5

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-ffmpeg-solaris10-sparc' triggered this build

Steps and Logfiles:

1. git update ( 12 secs )
   1. stdio
2. shell 'gsed -i ...' ( 2 secs )
   1. stdio
3. shell_1 'gsed -i ...' ( 1 secs )
   1. stdio
4. shell_2 'gsed -i ...' failed ( 0 secs )
   1. stdio
5. shell_3 './configure --samples="../../../ffmpeg/fate-suite" ...' failed ( 18 secs )
   1. stdio
   2. config.log
6. shell_4 'gmake fate-rsync' failed ( 0 secs )
   1. stdio
7. shell_5 '../../../ffmpeg/fate.sh ../../../ffmpeg/fate_config.sh' failed ( 0 secs )
   1. stdio
   2. configure.log
   3. compile.log
   4. test.log

Build Properties:

Forced Build Properties:

Responsible Users:

1. Jiasheng Jiang

   jiashengjiangcoolohnoyoudont@gmail.com
2. Kacper Michajłow

   kasper93ohnoyoudont@gmail.com

Timing:

All Changes:

:

1. Change #242899

   Category	ffmpeg
   Changed by	Jiasheng Jiang <jiashengjiangcoolohnoyoudont@gmail.com>
   Changed at	Wed 13 Aug 2025 13:50:26
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	b8d5f65b9e89d893f27cf00799dbc15fc0ca2f8e

   Comments

   libavfilter/dnn/dnn_backend_tf: Remove redundant av_freep() to avoid double free
   Remove redundant av_freep() to avoid double free since task will be freed in dnn_free_model_tf() after the success of ff_queue_push_back().
   
   Fixes: af052f9066 ("lavfi/dnn: fix mem leak in TF backend error handle")
   Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>

   Changed files

   • libavfilter/dnn/dnn_backend_tf.c

2. Change #242900

   Category	ffmpeg
   Changed by	Kacper Michajłow <kasper93ohnoyoudont@gmail.com>
   Changed at	Wed 13 Aug 2025 15:17:53
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	8eca3fa619a7fb2190a3d4203e01a0d2661e7f91

   Comments

   configure: use proper Windows-style static library naming
   On Windows, static libraries are typically named with a .lib extension.
   An exception to this is MinGW targets, which are treated as a distinct
   target-os.
   
   Using Windows-style naming allows `clang` to be used as the linker
   driver, instead of invoking link or lld-link directly. The latter
   approach requires manually specifying standard libraries when compiling
   with `clang` rather than `clang-cl`, and manually specifying standard
   libraries may be error-prone or incomplete.
   
   Using Windows-style naming allows Clang to be used as the linker driver,
   instead of invoking link or lld-link directly. The latter approach
   requires manually specifying standard libraries, which may be
   error-prone or incomplete.
   
   This change also improves support for LTO and sanitizer builds, where
   it's significantly easier to let the compiler driver manage the
   necessary linker flags.
   
   It fixes issues where Clang is asked to link `-lavcodec`, which gets
   passed to the linker as avcodec.lib, resulting in an error like:
   lld-link: error: could not open 'avcodec.lib': no such file or directory
   This happens because `libavcodec.a` was unexpectedly generated, not
   `avcodec.lib` expected by tooling.
   
   Additionally, using `clang` (not `clang-cl`) is simplified, as it does
   not use autolinking like MSVC/clang-cl does. Now `--ld=clang` can be
   used to add all the required libraries. Previously, building with
   `clang` was only possible by using `--ld=lld-link` and manually
   specifying system dependencies in `extra-ldflags`.
   
   Note that those changes doesn't affect mingw build. MSVC builds will
   produce .lib static libraries now, but the linking process itself is not
   affected, because filenames are passed directly.
   
   To summarize in Windows non-mingw builds:
   Static builds now produce `lib/avcodec.lib` instead of `lib/libavcodec.a`.
   Shared builds remain unchanged, producing `bin/avcodec.lib` together with
   `bin/avcodec-62.dll`.
   
   This also removes setting LD_LIB from Win32/64 target as there is one
   type of .lib in practice. We cannot build both shared and static at the
   same time as noted by the next line.
   
   Signed-off-by: Kacper Michajłow <kasper93@gmail.com>

   Changed files

   • configure