fixes ffmpeg linking issues on some setups and includes latest modplug, etc.

x86 GCC does not need those parameters to compile MMX or SSE assembly
or built-in intrinsics (contrary to ARM GCC w.r.t. NEON). They only
allow the compiler to issue MMX or SSE instructions for the plain C
code. We already rely on this tolerant compiler semantic for the CPU
detection code, and for some optionally accelerated filters (e.g.
deinterlace).

Disabling MMX and SSE for non-assembly code should have no or
negligible effects on the affected plugins. On the other hand, it
ensures that the plugin descriptor can be run by non-MMX/non-SSE CPUs.

Same as is done for MMX. Run-time checks determine whether SSE can be
used in any case.

Sorry for the problem.

This still needs a lot of fixing
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

So at least, someone can test/fix it...
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

CLose #4298

Should fix the issue mentionned on #3816, comment 14, 2 last results...

10l

(This does not affect directories and block devices.)

It is safe (out since 2 years) and it doesn't break the ugly win32 port
I did...

Should fix wiN32 contribs

It also fixes shared access to b_die without a lock(or equivalent) being used.

It's retarded for an installed file to depend on it

It breaks the build of pthread.

This reverts commit f8db78d5.
Signed-off-by: Pierre Ynard <linkfanel@yahoo.fr>

libmodplug is thread safe except when loading files or configuring settings
(before loading a file).