This seems to have been gone a long time ago and only references left
that have not been disturbing the build. Time to clean up!
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10793
This has not been used for a while and is not even buildable after our
switch to meson. It was a niche to start with given that it needed the
PS3 OS to run on. I asked for any remaining users at EDD and on the list
but heard nothing. Time to remove.
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10778
The documentation for these functions claims that passing a NULL array
results in doing nothing - that should also include logging nothing.
EINA_SAFETY_ON_NULL_RETURN() logs an ERR message and should be reserved
for usage when NULL is not actually a valid state.
Additionally, it's entirely possible to turn off EINA_SAFETY_CHECKS, at
which point these functions would stop behaving as the documentation
says they do. Not great.
Summary: Add checking on NULL like in other API in module, to avoid segmentation fault
Reviewers: NikaWhite, cedric
Reviewed By: cedric
Subscribers: myoungwoon, jpeg
Differential Revision: https://phab.enlightenment.org/D4383
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
we don't give any debug or info if a module in a list fails to load.
we should at least offer debug info. do that. this fixes coverity
issue CID 1039687
Failing to load a module that does not exist is indeed not an error,
but failing to load a module that exists on disk happened probably
because of an error like "symbol not found".
Considering eina_module is most likely used by EFL itself, I believe
an internal linking failure is a warning worth reporting.
it is not an error. eina_module may be used on files that don't exist
and the caller may handle that as a "does not exist" error. it is not
good to go spewing out errors for this. it's debug at best.
@fix
Summary:
When dlopen() fails, eina_module_load() print error information using dlerror().
But, it is printed with WRN. If EINA_LOG_LEVEL is lower than WRN,
application developer is hard to see which has a problem.
Reviewers: woohyun, Hermet, raster, cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2536
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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
Stefan Schmidt
Vincent Torri
Derek Foreman
Jean Guyomarc'h
Cedric BAIL
Artem Popov
Carsten Haitzler
Vincent Torri
Jean-Philippe Andre
Mike Blumenkrantz
Youngbok Shin
Shinwoo Kim
Mike Blumenkrantz
Cedric BAIL
Sebastian Dransfeld
Lucas De Marchi
Gustavo Sverzut Barbieri