Function implementations in the tkrzw module interface

[SchaichAlonso]

Hi

tkrzw has quite a bit of code that is implemented in header files that are supposed to be included by consuming projects. This causes some technical issues with weak symbols inside the consumer's translation units (or .obj files), that might fail to be deduplicated if the consuming project uses compiler settings different from those used by the tkrzw build system.

More importantly, however, parts of the code, especially non-virtual implementations, might end up being embedded into consuming applications by optimizers that eliminate the procedure calls, raising concerns considering licensing.

[estraier]

Hi,

Thanks for making the PR. However, let me ask some questions because I wrote some codes in the header files intentionally.

With --enable-debug, CFLAGS has -fno-inline, which avoids embedding of inline functions. Thus, you can trace inline functions on the debugger.
What are actual problems caused by weak symbols?
Embedding inline functions is useful for optimization. Whether to optimize them or not is up to the optimizer's decision.

As for licensing, Tkrzw uses the Apache2 license, not GPL3.
I'm not sure why using header files causes licensing problems.

[SchaichAlonso]

Hi,

Within itself (and its' tests/demos/examples), tkrzw forms a homogenous unit of CFLAGS and everything has the same license, too.
When another project attempts using tkrzw, by including its interface headers and linking against its' library, however, this is not neccessarily the case any more. "Random" projects have more or less "random" licenses, and their CFLAGS might be different from those used to build tkrzw, too.
If -fno-inline is used to the build of tkrzw, it will cause the tkrzw code not to be inlined within the tkrzw library. It does, however, not affect whether code of tkrzw is inlined into other projects that #include tkrzw code.
Independend of whether tkrzw has been built using -fno-inline, adding -fno-inline to the external projects' CFLAGS will stop tkrzw code from getting inlined into the external project, and getting mixed with foreign-licensed code there. However, the flag will also suppress inlining of any other function within the foreign code.

From a packaging/operations perspective, a goal would be the ability to replace tkrzw by replacing libtkrzw.so with an ABI-compatible version. If parts of tkrzw have ended up getting inlined into tkrzw-using binaries, then these binaries will need to be rebuilt and redeployed on top of tkrzw in order to swap tkrzw.

Note that in order to "inline" a function, an optimizer doesn't need the inline keyword, it only needs enough "knowledge"... i.e. non-virtual functions can almost always be inlined, unless they are decorated with compiler specific attributes, such as __attribute__(("noinline")), or a link unit wide policy like -fno-inline interdicts it.