First, I ain't sure we should display the mrl and not a "nice version of it"
Then I ain't sure that we should elipse on the left...
But, this is a beginning... Improvements welcome.

It is equal to (module_t.parent != NULL) and hence redumdant.

It is always false here.

On the one hand, plugins from different architectures cannot be mixed
in the same installation directory as they have the same names.
On the other hand, endianess and type sizes is way insufficient to
discriminate architectures (e.g. armel and i386 look the same).

So this was totally useless. And it did not need to be formatted at
run-time either.

The plugin cache does not depend on this anymore. It always contain all
plugins like it did in VLC versions <= 1.0. In theory, it could even be
generated at build-time if:
 * the compilation is native, and
 * the set of installed plugins is invariable.

On x86, describing and probing optimized plugins is safe (thanks to the
removal of the -mmmx and -msse2 compiler flags).

On PowerPC, libvlccore is built with -maltivec. This is a bug (no
difference before or after the plugin directory hack).
Describing and probing Altivec plugins is no worse.

On ARM, NEON support is detected only at compilation time currently
for lack of a better alternative. So this is a non-issue.

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>