Made this WIP because I've only done light testing on OSX. The basic idea is that the API should only be those symbols exposed in k.h. To completely hide the other symbols from the linker, you'd need to make them all static but you can also declare the visibility attribute. Then when the library is linked with -fvisibility=hidden only those with declared visibility can be linked against. (You can still see them with nm though.).
In addition, when building extensions (as opposed to embedding), the API points in link.so should be declared weak so that the symbols in the executable (strong by default) will take precedence.
In practice you shouldn't need to link against link.so at all since all the symbols in it will also exist in the executable (with the current build), and the weak declarations simply prevent the linking of the extension from failing.
As I say, I haven't tested this on linux yet so the exact mechanics may differ slightly. For instance on OSX I needed to add the link flag -undefined dynamic_lookup to tell it to not fail when there are missing symbols (because you don't link against libk.so) but rather expect the loader to find these symbols when the library is actually loaded.
There are nuances here I haven't fully grokked yet. Some stuff on the internet says that there's no difference between weak and strong symbols when using dlload, but I side step the issue by not linking against libk.so at all.
Made this WIP because I've only done light testing on OSX. The basic idea is that the API should only be those symbols exposed in `k.h`. To completely hide the other symbols from the linker, you'd need to make them all static but you can also declare the [visibility attribute](https://gcc.gnu.org/wiki/Visibility). Then when the library is linked with `-fvisibility=hidden` only those with declared visibility can be linked against. (You can still see them with `nm` though.).
In addition, when building extensions (as opposed to embedding), the API points in `link.so` should be declared [weak](https://en.wikipedia.org/wiki/Weak_symbol) so that the symbols in the executable (strong by default) will take precedence.
In practice you shouldn't need to link against `link.so` at all since all the symbols in it will also exist in the executable (with the current build), and the weak declarations simply prevent the linking of the extension from failing.
As I say, I haven't tested this on linux yet so the exact mechanics may differ slightly. For instance on OSX I needed to add the link flag `-undefined dynamic_lookup` to tell it to not fail when there are missing symbols (because you don't link against `libk.so`) but rather expect the loader to find these symbols when the library is actually loaded.
There are nuances here I haven't fully grokked yet. Some stuff on the internet says that there's no difference between weak and strong symbols when using `dlload`, but I side step the issue by not linking against `libk.so` at all.