tests: tool-frame checks the helpers as a realtime component

[grandixximo]

The test compiled kins_util.c into a userspace program with -DULAPI. Since kins_util.c exports its helpers for switchkins_core, EXPORT_SYMBOL is undefined there, which GCC 13 lets through as an implicit int and GCC 14 rejects, so the test failed to build on GCC 14. CI's rip-and-test job runs GCC 13, and the trixie and sid jobs skip the test, so it stayed green.

The checks now run in a component loaded after switchkins_core, which exports the helpers, the way tests/kins-jacobian checks the kinematics modules. A failed check fails the load. The checks themselves are unchanged.

tests/blendmath has the same problem since #4643 (EXPORT_SYMBOL(pmCircleEffectiveMinRadius)); that one is not addressed here.

Fixes #4670. Thanks to hdiethelm for the report and the bisect.

[grandixximo]

@BsAtHome tests/blendmath has the same GCC 14 failure as tests/tool-frame here. Since #4643, blendmath.c has EXPORT_SYMBOL(pmCircleEffectiveMinRadius). The test compiles blendmath.c with gcc and -DULAPI, where EXPORT_SYMBOL is not defined, and provides its own rtapi_print_msg stand-in.

The test checks only two functions, pmCartCartParallel() and pmCartCartAntiParallel(). My plan is to turn it into a component that runs the checks in rtapi_app_main(), loaded after tpmod, the way this PR does for tool-frame, with tpmod exporting those two functions.

But these are plain vector helpers, and gomath already has go_cart_cart_par(). Given your remark on #4623 about consolidating the gomath and posemath routines, would you rather see them move into that library and be tested there? What would you advise?

[BsAtHome]

But these are plain vector helpers, and gomath already has go_cart_cart_par(). Given your remark on #4623 about consolidating the gomath and posemath routines, would you rather see them move into that library and be tested there? What would you advise?

Essentially, moving it all into one library would save us from having to look all around. Consolidating it would be step two, if that is necessary.

I have currently no detailed overview who is using what. But it seems that the go routines are only in emc/kinematics/{userkfuncs.c,genserkins.h,genserfuncs.c}. If that is all, then it should be "easy" to eliminate the duplication?

[hdiethelm]

Thanks for the fix!

tests/blendmath has indeed the same problem since the last merge to master. But no hurry, i can work around it with -DRTAPI also with this one.

[hdiethelm]

Hmm, I assume that all code using EXPORT_SYMBOL should be built with -DRTAPI? In this case, it would make sense to add a #define EXPORT_SYMBOL(x) static_assert(false, "EXPORT_SYMBOL not defined with USPACE"); so the issue is not compiler version dependent any more.

There are a few tests using gcc:

tests/lowlevel/emcmot-error-mpsc/test.sh:gcc -O -pthread -DULAPI -Wall \
tests/lowlevel/mutex/test.sh:gcc -O -I"${HEADERS}" test.c -o test -DULAPI -std=gnu99 -pthread || exit 1
tests/blendmath/test.sh:gcc -O2 -Wall -ffunction-sections -fdata-sections -DRTAPI -DUNIT_TEST \
tests/build/header-sanity/test.sh:    gcc ${CPPFLAGS} -DULAPI -I"$HEADERS" -E -x c "$i" > /dev/null
tests/tool-frame/test.sh:gcc -O2 -Wall -ffunction-sections -fdata-sections -DRTAPI \
tests/inifile/ini_api_c/test.sh:gcc "${FLGS[@]}" -o initest  initest.c -llinuxcncini || { echo "Failed compile"; exit 1; }

They are probably all problematic: Just as a starter, they take gcc and not clang, even if you build linuxcnc with clang or define a different gcc version. Would it make sense to add a submakefile for the tests and not build in a .sh?

[grandixximo]

@hdiethelm thanks. tests/blendmath is fixed in #4676: its two functions move into posemath and the test becomes a component loaded after tpmod, like tool-frame here. That PR also removes gomath, which answers the consolidation question above.

The static_assert guard makes sense to me as a separate rtapi.h change. Shared code such as hal_lib.c already wraps its exports in #ifdef RTAPI, so an unguarded one in a ULAPI build means module code compiled in userspace, which only these tests did. @BsAtHome, would you take that in rtapi.h?

On gcc in test.sh: tests of module code are becoming halcompile'd components, which also use the configured compiler. Of the others, lowlevel/emcmot-error-mpsc still compiles tree sources (emcmotutil.c, dbuf.c) and is the next candidate; mutex, ini_api_c and header-sanity only build their own files.