avidemux_cli 2.6.8 - missing libgcc_s_sjlj-1.dll ?

[LigH]

A user in the German doom9/Gleitz forum reports that the GUI version of Avidemux 2.6.8 v2 (32bit) works, but avidemux_cli.exe fails starting due to a missing libgcc_s_sjlj-1.dll ... the installer apparently does not ship this DLL which looks like a cygwin runtime library. He reports that older versions of Avidemux ship older versions of this DLL, just not the current 2.6.8 v2. Is it possible to install a matching version in addition, or would it be necessary to fix the Avidemux installer?

I must confess I did not yet try that, I don't have a useful PC for this purpose right here and now...

[LoRd_MuldeR]

This DLL is not a Cygwin runtime library, but the GCC runtime library (SetJump/LongJump version). Cygwin also provides a GCC, but programs compiled by MinGW's GCC do not use/need Cygwin runtime.

You will probably need the "libgcc" DLL that matches the exact GCC/MinGW version that was used to create that particular build of Avidemux. The required DLL really should be included in the Avidemux installation package.

BTW: Latest Avidemux v2.6.11 seems to ship with all required DLL's.

[LigH]

I never saw this DLL in conjunction with static MSYS builds so far; maybe the projects I saw were just successful regarding the correct generation of static builds.

I'll forward your suggestion. But I remember one constraint was running on Windows XP SP3, and I wonder if Avidemux 2.6.11 would still.

Not my problem, though. XP is obsolete now. Even W7 is already dying.

[LoRd_MuldeR]

From GCC docs:

-shared-libgcc
-static-libgcc

On systems that provide libgcc as a shared library, these options force the use of either the shared or static version, respectively. If no shared version of libgcc was built when the compiler was configured, these options have no effect.

There are several situations in which an application should use the shared libgcc instead of the static version. The most common of these is when the application wishes to throw and catch exceptions across different shared libraries. In that case, each of the libraries as well as the application itself should use the shared libgcc.

Therefore, the G++ and GCJ drivers automatically add -shared-libgcc whenever you build a shared library or a main executable, because C++ and Java programs typically use exceptions, so this is the right thing to do.