As there's non-inline implementation of appl_init() in a_glue.c,
I guess one could just ifdef the static inline function out from
gem.h header. Currently there are no such compiler specific ifdefs
in gem.h though.
Ah! i think i've missed the context of your initial post.
gemlib can be built (and used) out-of-the-box for several compilers (old gcc 2.81, gcc 2.95, current gcc, sozobonx, purec) thanks to compiler.h (provided with gemlib).
So, if you want to port gemlib for another compiler, i think you should update compiler.h for your compiler.
This is the clean way. It already works that way for a lot of "old" compilers (which don't know what "inline" is).
(if the size of the application is really a problem because of this inline call, then gemlib should be optimized, but it's another subject)
Now, a side note about a_glue.c :
This piece of code is only used for one purpose: to cover the case of an application linked against 2 librairies:
- current version (0.43) of gemlib
- an old closed-source GEM library that has been compiled against gemlib 0.42, and that has not been rebuilt against gemlib 0.43.
This old closed-source GEM library requires symbols like "appl_init", "appl_exit", "wind_set" to be linked to... but gemlib 0.43 only provides "mt_appl_init", "mt_appl_exit", "mt_wind_set".... and a_glue.c is here to make the glue between old gemlib 0.42 symbols and new gemlib 0.43.
I think a_glue.c has never been used; and maybe there are bugs in a_glue.c... Furthermore, the prototype of some AES functions has changed between gemlib 0.42 and gemlib 0.43 and a_glue.c should contain the prototype of gemlib 0.42
To sum-up, it's a bad idea to use any function of a_glue.c.
Other consequence of a_glue.c : if you use one function of a_glue.c, then the whole module "a_glue.o" will be linked in the binary, and as a_glue.c calls nearly all AES functions of gemlib, then the whole AES part of gemlib will be included in the binary (the binary may become a lot bigger).