Summary:
Patch from a series of patches to rename EAPI symbols to specific
library DSOs.
EAPI was designed to be able to pass
`__attribute__ ((visibility ("default")))` for symbols with
GCC, which would mean that even if -fvisibility=hidden was used
when compiling the library, the needed symbols would get exported.
MSVC __almost__ works like GCC (or mingw) in which you can
declare everything as export and it will just work (slower, but
it will work). But there's a caveat: global variables will not
work the same way for MSVC, but works for mingw and GCC.
For global variables (as opposed to functions), MSVC requires
correct DSO visibility for MSVC: instead of declaring a symbol as
export for everything, you need to declare it as import when
importing from another DSO and export when defining it locally.
With current EAPI definitions, we get the following example
working in mingw and MSVC (observe it doesn't define any global
variables as exported symbols).
Example 1:
dll1:
```
EAPI void foo(void);
EAPI void bar()
{
foo();
}
```
dll2:
```
EAPI void foo()
{
printf ("foo\n");
}
```
This works fine with API defined as __declspec(dllexport) in both
cases and for gcc defining as
`__atttribute__((visibility("default")))`
However, the following:
Example 2:
dll1:
```
EAPI extern int foo;
EAPI void foobar(void);
EAPI void bar()
{
foo = 5;
foobar();
}
```
dll2:
```
EAPI int foo = 0;
EAPI void foobar()
{
printf ("foo %d\n", foo);
}
```
This will work on mingw but will not work for MSVC. And that's why
EAPI is the only solution that worked for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Reviewers: jptiz, lucas, woohyun, vtorri, raster
Reviewed By: jptiz, lucas, vtorri
Subscribers: ProhtMeyhet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12188
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