-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[misc] Statically linked raylib exposes functions from src/external/*
#4207
Comments
src/external/*
src/external/*
AFAIK, -fvisibility=hidden does not function for static libraries. |
Many of the functions from external libraries can be defined to have internal linkage using macros like #define MA_API static this would let the compiler discard the unused ones at compile time and produce better code for those which are used. Since this would produce a lot of noise from all the unused function warnings, depending on the compiler, something like #ifdef __GNUC__
# define MA_API __attribute__((unused)) static
#endif This can be generalized in a similar way as the For external libraries that don't allow it, I haven't tried yet but I have some ideas involving the use of the |
That proposal makes sense, thanks for the details. Most of this can be avoided with LTO for static libraries but it would help in some cases for the shared lib too. |
@ListeriaM What is exactly the bloat added from those functions? Personally I like them exposed because I use them sometimes on my user code just including the required .h and knowing the implementation is available in static raylib. What I find more worrying is the shared library not exposing them. What was the proposed changed/solution? |
What I was refering to as bloat is precisely the hidden functions in the shared library, they are defined but they cannot be used. If they were removed (or exposed), then static and shared raylib would be interchangeable. So the problem is not necessarily that they're accessible in static raylib, but rather the difference in the APIs from static and shared. The solution depends on the decision of removing or exposing them. I think removing them is the better option, since I don't consider them part of the raylib API, and I was surprised when I tried to use one of these headers in my code and got a linker error. If they were not exposed using them in your code would be as simple as defining In any case the first step would be to use the |
Just to note, I made the change to use -fvisibility=hidden but there would still be a problem with windows dlls, which effectively act that way by default. I did it to hide glfw. So there would still be inconsistency between the so and a dll, even if using -fvisibility=hidden was reverted. |
I agree with this reasoning. Especially for header-only libraries, it is okay to have multiple copies, I think whatever solution is proposed for static linking should make it okay to just define the implementation in your own code, regardless of what raylib has. |
Unfortunately, afaik, not all the internally used libraries expose some way to remove the symbols and that would imply some symbols removed and some exposed. Would it be possible to expose all the symbols in both static and shared libraries? If not possible to find a really consistent solution, then I'd just left as inconsistent as it is now, I think most user will never case about it. |
Is there possibly a confusion here between debug and release builds? For static linking, unreachable functions can be eliminated from the executable and that should relieve any concern about bloat. There's no way to know for a shared library, but I would think that externally-unreachable (i.e., static) functions would not have symbols in the shared library, although I can understand why they might have to. |
Linkers cannot remove symbols, even when static linking, most of the time, certainly not without extra flags. It is something you need to request and arrange to happen - not default in most circumstances. |
Got it. With the Windows Visual Studio Build Tools you do need to specify an option to the compiler and another in the static linking. I do that habitually with raylib apps, and the |
src/external/*
src/external/*
Environment
make
Issue description
Some of the single header libraries used by raylib expose a macro that affects the linkage of functions defined in them (i.e:
MA_API
forminiaudio.h
), but these are not used by raylib. The result is that all of their functions are included in the final library (static or shared), this is evidenced by the output fromobjdump
below. In the case of the shared library these are not accessible due of the use of-fvisibility=hidden
in the Makefile (Linux, BSD & OS X), but they are still included in it, even if unused (and inaccessible in the case of the shared library). All of these functions bloat raylib considerably.Code Example
Take
ma_version()
fromminiaudio.h
for example, it is not used by raylib, yetobjdump -j.text --disassemble=ma_version libraylib.so
shows its definition (we would see similar output fromlibraylib.a
):The fact that they are visible in the statically linked version means that we can do something like this:
and get different output using the static or the shared library:
The text was updated successfully, but these errors were encountered: