Add some ramblings about symbol visibility
Symbol visibility is a huge issue that we need to address.
The current way of doing so has considerable downsides, but also gurantees some form of safety. This tries to expand the internal developer guide a bit to describe the three different problems we have.
Personally I believe that there is not possibility for us as library authors to ever solve the problem of different architectures for all possible scenarios.
The moment a user puts any function or type that calls a kernel into a library the issue reappears and there is nothing we can do about it.
The moment a user puts any function or type that calls a kernel into a library the issue reappears and there is nothing we can do about it.
This is true, unless the library author knows about this problem and is taking the necessary precautions, e.g., RAPIDS.
For those cases, in order for them to do the right thing, they still depend on us to do the right thing with our symbols.
In other words, for a well-formed user program, it is necessary, but not sufficient, for us to properly guard our symbols.
i learned recently about the GNU __abi_tag__ attribute which we can use to make symbols unique where it is supported. i'm not certain if our toolchain supports it.