Closed heuripedes closed 9 years ago
Are you suggesting adding attribute((visibility("default"))) to libretro.h?
If yes, post a PR, including your plans for how to not confuse frontends and other devices that don't have any retro_run to export.
If no, the correct repo for multi-core issues is libretro-super; this repo is only for libretro.h itself. Visibility attributes and (as far as I know) linker scripts work fine without changing the headers; here's an example.
(e: github is stupid)
Are you suggesting adding attribute((visibility("default"))) to libretro.h?
Yes.
If yes, post a PR, including your plans for how to not confuse frontends and other devices that don't have any retro_run to export.
AFAIK It shouldn't affect the ABI at all, if anything the compiler/linker might add more meta data into the symbol table.
Visibility attributes and (as far as I know) linker scripts work fine
They do but they only matter to the linker.
https://github.com/Alcaro/minir/blob/master/subproj/testcore.cpp#L296
That's exactly what I'm talking about.
It would be nice to make
retro_*
symbols explicitly public so that the user is free to use flags like-fvisibility=hidden
on his cores without getting undefined references toretro_*
symbols issues. According to this article one can get better code generation and improved loading times by defaulting symbol visibility to hidden. These advantages apply to both C and C++ code but the result is more noticeable with C++. The article cites an use case where the developer was able to reduce the DSO file size by 21MB so the flag can probably benefit huge cores like mame and PPSSPP.My use case: I just started working on a C++ core and using
-fvisibility=hidden
reduces the shared object size by about 100KB in debug mode and ~70KB in release mode but the frontend is unable to load libretro symbols because these are not public/exported.