Closed hmartinez82 closed 6 months ago
Our nightly builds are using MSYS2 and MINGW64 (GCC 13.2).
The workflow file is here: https://github.com/mltframework/shotcut/blob/master/.github/workflows/build-windows.yml Here is last night's run: https://github.com/mltframework/shotcut/actions/runs/8213183222
A quick google search for "unknown target exception" suggests this is a common message when the GDB version does not match the GCC version (64/32 bit)
I'm afraid you are unlikely to find much help on this forum since we do not recreate the problem with our build system.
@bmatherly Could you try building in Debug mode? Surprisingly I only see this error when I tried to build mlt in Debug build type:
-- Build files have been written to: D:/Dev/Github/MINGW-packages/mingw-w64-mlt/src/build-MINGW64
[92/311] Building C object src/framework/CMakeFiles/mlt.dir/mlt_repository.c.obj
FAILED: src/framework/CMakeFiles/mlt.dir/mlt_repository.c.obj
C:\msys64\mingw64\bin\gcc.exe -DDLFCN_WIN32_SHARED -DNODEPLOY -Dmlt_EXPORTS -ID:/Dev/Github/MINGW-packages/mingw-w64-mlt/src/mlt-7.18.0/src/framework/.. -march=nocona -msahf -mtune=generic -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong -ggdb -Og -ffile-prefix-map=/d/Dev/Github/MINGW-packages/mingw-w64-mlt/src=/usr/src/debug/mingw-w64-mlt -Wno-int-conversion -Wall -Werror -Wno-deprecated-declarations -Wno-discarded-qualifiers -g -std=gnu11 -mmmx -msse -msse2 -MD -MT src/framework/CMakeFiles/mlt.dir/mlt_repository.c.obj -MF src\framework\CMakeFiles\mlt.dir\mlt_repository.c.obj.d -o src/framework/CMakeFiles/mlt.dir/mlt_repository.c.obj -c D:/Dev/Github/MINGW-packages/mingw-w64-mlt/src/mlt-7.18.0/src/framework/mlt_repository.c
In file included from C:/msys64/mingw64/include/_mingw.h:10,
from C:/msys64/mingw64/include/corecrt.h:10,
from C:/msys64/mingw64/include/crtdefs.h:10,
from C:/msys64/mingw64/include/inttypes.h:11,
from X:/Github/MINGW-packages/mingw-w64-mlt/src/mlt-7.18.0/src/framework/mlt_types.h:34,
from X:/Github/MINGW-packages/mingw-w64-mlt/src/mlt-7.18.0/src/framework/mlt_profile.h:26,
from X:/Github/MINGW-packages/mingw-w64-mlt/src/mlt-7.18.0/src/framework/mlt_repository.h:26,
from X:/Github/MINGW-packages/mingw-w64-mlt/src/mlt-7.18.0/src/framework/mlt_repository.c:23:
In function 'snprintf',
inlined from 'list_presets' at X:/Github/MINGW-packages/mingw-w64-mlt/src/mlt-7.18.0/src/framework/mlt_repository.c:583:25:
C:/msys64/mingw64/include/stdio.h:458:3: error: call to '__mingw_chk_fail_warn' declared with attribute warning: Buffer overflow detected [-Werror=attribute-warning]
458 | __mingw_bos_ptr_chk_warn(__stream, __n, 1);
| ^~~~~~~~~~~~~~~~~~~~~~~~
cc1.exe: all warnings being treated as errors
[117/311] Building C object src/modules/avformat/CMakeFiles/mltavformat.dir/producer_avformat.c.obj
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().
Aborting...
That is probably happening because we treat warnings as errors when compiling in debug mode: https://github.com/mltframework/mlt/blob/master/CMakeLists.txt#L148
I eventually get around to fixing these when I am forced to upgrade my system and the new version of GCC triggers new warnings. I'm not available to help reproduce and debug this right now. But maybe you can make a quick patch to satisfy the warning/error. If you do, send it my way and I can merge it in to master.
I got around by replacing the three usages of snprintf
with _snprintf
. Now not only the debug build completes. The error is gone, and is fixed in Release too😮
@bmatherly I think I found out. And still using snprintf
instead of _snprintf
:
https://github.com/mltframework/mlt/blob/7930382303eb2c1c044bd68e8b40dcf99e5a9b63/src/framework/mlt_repository.c#L584 should use sizeof(fullname)
instead of 1024
Weird. Our SDK builds in debug mode and has not experienced the build error https://github.com/mltframework/shotcut/actions/workflows/build-sdk-windows.yml
OS:
MINGW64_NT-10.0-22631 3.4.10.x86_64 2024-02-10 08:39 UTC x86_64 Msys
MLT:7.22.0
Shotcut:24.02.29
GCC:13.2.0
MinGW 64 builds of Shotcut are crashing at startup when using MSYS2's MINGW64 environment. Surprisingly this is only affecting GCC builds. The Clang builds in both CLANG64 and CLANGARM64 do not show this issue.
Steps to reproduce:
QSG_RHI_BACKEND=d3d11
(This was done so gdb would attach to the right process)Expected
Actual
GDB's backtrace provided: