Summary:
I got an issue from emotion_basic_example, because my machine has following directories.
/usr/local/lib/emotion/modules/
├── gstreamer
│ ├── linux-gnu-i686-1.7.99
│ ├── linux-gnu-i686-1.8.0
│ └── linux-gnu-i686-1.8.99
└── gstreamer1
├── linux-gnu-i686-1.8.99
└── v-1.10
The defined MODULE_ARCH is v-1.10, and the _emotion_modules which is returned by eina_module_arch_list_get(); has two items.
Because eina_module_new(); creates Eina_Module, even though the "/usr/local/lib/emotion/modules/gstreamer/v-1.10/module.so"
does not exist.
Test Plan: Create directory without MODULE_ARCH, run emotion_basic_example, and check whether it works properly or not.
Reviewers: raster, seoz, Hermet, woohyun, jpeg, cedric
Subscribers: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D1200
Signed-off-by: Cedric BAIL <c.bail@partner.samsung.com>
this makes efl ignore certain env vars for thnigs and entirely removes
user modules (that no one ever used) etc. etc. to ensure that *IF* an
app is setuid, there isn't a priv escalation path that is easy.
so firstly the module loading logic in emotion is pretty bad. it
forcible loads into memory (dlopen + run code from) EVERY emotion
module whenever you use emotion anywhere. this is a fat memory cost and
startup cost. it should not ever have done this. so remove that code
and make it explicitly load only the backend requested and fall back
to using what is compiled in (generic by default) and otherwise
generic as a module, then xine, then gstreamer then gstreamer1.
gstreamer1 seems broke - all i see is a black box (no video).
this also fixes a deadlock problem. if you have BOTH gstreamer AND
gstreamer1 modules loaded i get a deadlock inside glib. this seemingly
fixes it as it'll only load the first one it finds, not both (unless
explicitly requested).
it's still not merged into EFL single tree, but once it is we should
use "HAVE_EXOTIC" define to work with it.
Before we had: EINA_HAVE_EXOTIC (not used), HAVE_EXOTIC_H (used by
eina_module.c). Since the other libs are all defined as HAVE_LIBNAME,
we're using HAVE_EXOTIC everywhere now.
SVN revision: 77816