Skip to content

Conversation

@mathsen
Copy link

@mathsen mathsen commented Jan 2, 2026

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
Copy link
Author

mathsen commented Jan 5, 2026

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant