libsc: detect and link libm explicitly for math-using examples

[mathsen]

Some libsc example programs (notably the v4l2 example) use math functions such as sin(). On many platforms these reside in libm, but the build system previously relied on implicit or transitive linkage, which is no longer reliable with newer toolchains and linkers.

Problems are reported downstream e.g. here and one can see workarounds like adding globally "-lm" e.g. here.

[mathsen]

I further looked at the issue and saw that e.g. debian still bundles p4est 2.3.6, where the bundled sc version uses a different mechanism to detect libm.
On current master, SC_CHECK_MATH is used for this purpose and is intended to detect libm.

SC_CHECK_MATH uses sqrt() directly in its link test.
With GCC at -O2, sqrt may be expanded as a builtin and lowered to an instruction sequence (e.g. SSE sqrtsd), so the conftest object contains no unresolved sqrt symbol. In this case configure reports “none required” and does not add -lm.

This was observed with /usr/bin/gcc, where nm -u on the conftest object showed no undefined sqrt symbol. However, the full build later fails to link once libsc or example code references non-builtin libm symbols such as sin/cos/log/exp/lgamma/ceil/floor.

Call sqrt through a volatile function pointer in the probe to force an external reference and make SC_SEARCH_LIBS reliably add -lm when needed.

An earlier version of this PR used AC_SEARCH_LIBS([sin], [m]). While that already improves the situation, the function-pointer approach stays closer to the existing SC_SEARCH_LIBS-based implementation and avoids relying on compiler-specific assumptions about which math functions may or may not be expanded as builtins.

[cburstedde]

Thanks for your detailed and clear reasoning! If you would like to add a file doc/author_<lastname>.txt like the others? Even though technically you're not adding code to the library.

…

I further looked at the issue and saw that e.g. debian still bundles [p4est 2.3.6](https://packages.debian.org/source/stable/p4est), where the bundled sc version uses a different mechanism to detect libm. On current master, `SC_CHECK_MATH` is used for this purpose and is intended to detect libm. `SC_CHECK_MATH` uses `sqrt() `directly in its link test. With GCC at -O2, sqrt may be expanded as a builtin and lowered to an instruction sequence (e.g. SSE sqrtsd), so the conftest object contains no unresolved sqrt symbol. In this case configure reports “none required” and does not add -lm. This was observed with /usr/bin/gcc, where nm -u on the conftest object showed no undefined sqrt symbol. However, the full build later fails to link once libsc or example code references non-builtin libm symbols such as sin/cos/log/exp/lgamma/ceil/floor. Call sqrt through a volatile function pointer in the probe to force an external reference and make `SC_SEARCH_LIBS` reliably add -lm when needed. An earlier version of this PR used AC_SEARCH_LIBS([sin], [m]). While that already improves the situation, the function-pointer approach stays closer to the existing SC_SEARCH_LIBS-based implementation and avoids relying on compiler-specific assumptions about which math functions may or may not be expanded as builtins.

[mathsen]

Thanks for the suggestion!
I’ve added an author-doc file in a follow-up update.
That said, I’m completely fine either way if you prefer not to merge it - since my contribution is limited to build-process changes and doesn’t touch the library code itself.

[cburstedde]

Thanks again! This is an elegant way of solving the problem.