I the past week I put together very quickly a working prototype for a game framework that hot-reloads both code and assets, losely based on the handmade aproach (https://youtu.be/WMSBRk5WG58?si=oHDSAOOzF-2e0PoM).
I has a bootstrap.exe, core.dll and game.dll.
The bootstrap is responsible to loads both the code and game dlls and to reload the later when it changes, the core.dll is imutable it can not be reloaded because it holds global state comming from libraries such as raylib, imgui… The game.dll is linked against core.dll and where all the game logic resides, pretty standard sutff.
Now the trick part, I developed a zig framework that I wish to use instead of raylib and the only way I know to make this work is by exporting all of my functions, and to make all structs extern and then write zig bindings for my zig lib 
Is there any other way of consuming a zig shared library from zig without needing to export symbols?
1 Like
export and extern(on decls) are for cross object exposing and using symbols. pub and @import only work within an object, not across multiple.
And zig doesnt have a stable abi, so you have to wrap that aswell, usually you’d use the c abi, which is the default.
you dont have to make everything compatible with the abi, only the exposed api needs to be, and that can just be a wrapper over the zig api
Keeping a header file and a c file was always one of my biggest pain points when using c/c++ and also one the most important reasons why I switched to something else.
I often make my globals extern and let the functions as is, the globals have to be defined and exported in a separated file, but this is the quickest way.
For functions, I usually implement them normally as if I was just writing zig, then in a separated file I export them and in another file I reimplement the zig interface but calling the exported function, the exported functions have to be redefined using the extern keyword.
This sucks, it duplicates quite a bit of code and adds tons of boilerplate, not to mention that there is nothing from keeping the export and extern definitions the same, any change to the api requires the modification in 5 different places…