If your API is c++ based, you ship a static lib. If the game engine is "closed" source, you also a have static lib (or a set of) for the game engine too, and "exporting" is actually linking (basically a binutils ld invokation). Ofc, you better use the same c++ compiler _VERSION_ than the game engine devs did use, or you are good for c++ hell.
If your API is C based (or core platform ABI), and you should design such API for interop with any framework anyway, you can ship a shared lib (but it has to statically load only the common glibc libs, and that with "old" symbol versions, and the other things too, see my previous post).
If your API is c++ based, you ship a static lib. If the game engine is "closed" source, you also a have static lib (or a set of) for the game engine too, and "exporting" is actually linking (basically a binutils ld invokation). Ofc, you better use the same c++ compiler _VERSION_ than the game engine devs did use, or you are good for c++ hell.
If your API is C based (or core platform ABI), and you should design such API for interop with any framework anyway, you can ship a shared lib (but it has to statically load only the common glibc libs, and that with "old" symbol versions, and the other things too, see my previous post).