Generated C should use export macros

[alexreinking]

The generated C code should stamp exported functions with <LibName>_API macros to explicitly mark their symbols as exported. This varies by compiler and should be user-overridable. This will be necessary to play nice on Windows at all and to support Unix-y users compiling with -fvisibility=hidden.

[gilbo]

Does this mean e.g. if I write a library that exports functions matmul2d() and conv2d(), that there would be some kind of option which would change those to matmul2d_MYLIB_API() and conv2d_MYLIB_API()? Or do you mean something else here?

…

On Jun 14, 2022, at 3:29 PM, Alex Reinking ***@***.***> wrote: The generated C code should stamp exported functions with <LibName>_API macros to explicitly mark their symbols as exported. This varies by compiler and should be user-overridable. This will be necessary to play nice on Windows at all and to support Unix-y users compiling with -fvisibility=hidden. — Reply to this email directly, view it on GitHub <#200>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKZHLEIVNEMVVMF4HBGUGLVPEBTNANCNFSM5YZIEMLQ>. You are receiving this because you are subscribed to this thread.

[alexreinking]

No, it would selectively add (on gcc, for example) __attribute__ ((visibility ("default"))) before a function definition.

See the GCC docs here for some more discussion: https://gcc.gnu.org/wiki/Visibility

[rachitnigam]

@SamirDroubi mentioned that this is probably for building dynamically compiled C libraries from Exo code. This is quite a low priority so not sure when we'd work on it.

[alexreinking]

No, this is for building shared libraries correctly. This will prevent symbol resolution issues that arise when loading two shared libraries, both of which are written in Exo.