Vendored Cephes library overrides common math functions, should this be changed?

[tly000]

The vendored Cephes library contains some math functions that are also in the default c runtime math libraries on Linux and Windows. Some of them that come to mind:

• round, cbrt, exp2, exp10, yn, (maybe more?)

This leads to some unexpected behavior when linking GTSAM, the default math functions might actually be replaced by the Cephes versions, which might behave differently than the platform-defined functions and might be slower.

Some reasons why those functions might be replaced:

• Linux: Statically linking GTSAM but dynamically linking libc/libm: Due to symbol interposition, the symbols from the main executable are preferred over the symbols from the shared library.
• Windows: Statically linking GTSAM but dynamically linking the MSVC runtime library: The Windows linker prefers symbols from static libraries over those from shared libraries, this means the functions might also be replaced.

Note: When linking both GTSAM and the standard library statically, there should be "multiple definition" linker errors, i can at least confirm that on Windows.

Should this be fixed? I think the easiest fix right now would be to only build igami.c from cephes, or even copying this one file from Cephes instead of vendoring the whole library (if the license permits it).

[Gold856]

There was discussion in #2273 about those <cmath> functions. The header was giving issues when compiling statically, so I fixed that by modifying the header, but I forgot that the symbols were still compiled in. I'm definitely in favor of cutting down our vendored copy of cephes to just the core files (which is actually 13 files). That was rejected, but I think we ought to give it another chance.

[ProfFan]

On this topic, I would like to at least namespace these functions so that they won't cause symbol clashes.

[Gold856]

I'm not sure how I feel about namespacing since the library is vendored in almost unmodified form, and I like keeping modifications to a minimum. I doubt symbol clashes will be common after we cut down the library anyways. The remaining files shouldn't share any symbols with anything except for another cephes copy, which should be the same as the one we have, so the symbols can be safely merged.

If we're really paranoid, we could always statically link cephes into gtsam itself and throw on a -fvisibility-hidden for safety. It's kinda weird having this extra cephes library as its own separate file.

[dellaert]

If we can do it without violating the license of cephes, I'm all in favor of cutting down to exactly what we need.

[ProfFan]

btw, Cephes has not been released under MIT license, instead, sources like https://github.com/nearform/node-cephes/blob/master/LICENSE all pointed out that it's released under a BSD license per discussions with the author.

In any case, we should update the license file

[Gold856]

It looks like the README file points to a valid MIT license for cephes? I think it's well established at this point that the author is willing to license cephes under a permissive license, so I think it's fine to keep it as MIT (especially if it was licensed as such to someone already.)