build forte for PFC200

[moniwe]

I created the following configuration to build forte for a PFC200 from Wago:

ARCH=arm-linux-musleabihf

DEPS=tinyxml

COM=ETH,FBDK,LOCAL,HTTP

// IEC61131,RT_Events,UTILS,RECONFIGURATION MODULE=CONVERT,UTILS_ADDON,CUSTOM_FBS

CMAKE_BUILD_TYPE=Debug FORTE_LOGLEVEL=LOGDEBUG

// address sanitizer doesn't work with static linking TOOLCHAIN_EXTRA_C_FLAGS=-fno-sanitize=address -fno-lto TOOLCHAIN_EXTRA_LINKER_FLAGS=-fno-sanitize=address -fno-lto

FORTE_IO=ON FORTE_MODULE_WagoKbus=ON FORTE_WAGO_INCLUDE_DIR=/mnt/d/Development/com/4diac/git/fordiac-rte/wago/include FORTE_WAGO_LIB_DIR=/mnt/d/Development/com/4diac/git/fordiac-rte/wago/lib

building it without the IOs forte runs on PFC200, but when I add the IOs it seems to miss a header file:

/mnt/d/Development/com/4diac/git/fordiac-rte/wago/include/OsLinux/OsCommon.h:30:10: fatal error: sys/cdefs.h: No such file or directory 30 | #include <sys/cdefs.h> | ^~~~~ compilation terminated.

maybe libc6-dev-armhf-cross is needed? In case this is true, how would it be added?

[moniwe]

@jwalt unfortunately i still cannot add you as assignee

[jwalt]

That header is exclusive to GNU libc. The wago library seems to be mildly incompatible with musl libc, which we use for static binaries (glibc doesn't support static linking very well). There are two workarounds:

• use ARCH=arm-linux-gnueabihf which has this header but may fail in other ways
• edit the wago includes to remove that line and hope that it isn't needed on musl libc / find what the correct include is for musl libc

[moniwe]

thank you for your suggestions. I tried workaround 2. It seems that only 2 Makros have been used, which i was able to replace somehow, I think. But in the end I got these messages wago.log while linking.

I also tried to create a docker container with the compiler they provide here and then a shell script that compiles forte "old school", means not with the forte build environment. But the docker requires a newer cmake and this newer cmake somehow does not find the compiler. I tried to add PATH, CC and CXX environment variables, but cmake was not satisfied.

Do you have any further advice?

[jwalt]

Okay, there are lots of shared libraries used during linking. If these were provided by the vendor as binary-only libraries, ARCH=arm-linux-gnueabihf is your only chance, and in fact this is the use case for which I added that toolchain in the first place. The build system tries to be smart to package all shared libraries in a way that the result is still somewhat self-contained, but this is a less-tested code path.

If you have full source code for the wago libraries, you can also build static libraries using 4diac-fbe (use existing recipes as template for new ones) and stay with the default static-linking musl toolchain.

Please consider submitting relevant configs/recipes/code for that platform. configurations/test/... is a place where you can add configurations for exotic platforms not yet covered by our build tests.

[moniwe]

I tried with arm-linux-gnueabihf, the list is shorter now pfc200.log unfortunately my tries to let it find this library failed, I assumed it might be this one within the image or that within sysroot/lib32 but I did not figure out where I let it know that the library is there. Any advice on that?

[jwalt]

The root cause of the problems was using

forte_add_link_library(libdal.a liblibloader.so libpthread.so libffi.so libdbus-glib-1.so libglib-2.0.so librt.so)

(full library filenames) instead of the shorter and recommended

forte_add_link_library(dal libloader pthread ffi dbus-glib-1 glib-2.0)

(only the library basename), letting cmake+gcc sort out the details. The mix of .a and .so libraries triggered cmake to forcefully switch between static and dynamic linking, resulting in an attempt to link a static libgcc_s.a, which cannot exist due to its very purpose.