When testing my package, I found a series of similar problems when building (current master branch) for some platforms. For instance: $ utils/test-pkg -k -a -p libmdbx andes-nds32 [ 1/45]: FAILED arm-aarch64 [ 2/45]: FAILED bootlin-x86-64-glibc [ 3/45]: FAILED br-aarch64-glibc [ 4/45]: FAILED br-arcle-hs38 [ 5/45]: OK br-arm-basic [ 6/45]: OK br-arm-cortex-a9-glibc [ 7/45]: FAILED br-arm-cortex-a9-musl [ 8/45]: OK br-arm-cortex-m4-full [ 9/45]: SKIPPED br-arm-full [10/45]: OK br-arm-full-nothread [11/45]: SKIPPED br-arm-full-static [12/45]: OK br-i386-pentium4-full [13/45]: OK br-i386-pentium-mmx-musl [14/45]: OK br-m68k-5208-full [15/45]: SKIPPED br-m68k-68040-full [16/45]: OK br-microblazeel-full [17/45]: FAILED br-mips32r6-el-hf-glibc [18/45]: FAILED br-mips64-n64-full [19/45]: OK br-mips64r6-el-hf-glibc [20/45]: FAILED br-mipsel-o32-full [21/45]: OK br-nios2-glibc [22/45]: FAILED br-openrisc-uclibc [23/45]: OK br-powerpc-603e-basic-cpp [24/45]: OK br-powerpc64le-power8-glibc [25/45]: FAILED br-powerpc64-power7-glibc [26/45]: FAILED br-powerpc-e500mc-full [27/45]: OK br-riscv32 [28/45]: FAILED br-riscv64 [29/45]: FAILED br-riscv64-musl [30/45]: OK br-sh4-full [31/45]: OK br-sparc64-glibc [32/45]: FAILED br-sparc-uclibc [33/45]: SKIPPED br-x86-64-core2-full [34/45]: OK br-x86-64-musl [35/45]: OK br-xtensa-full [36/45]: OK linaro-aarch64-be [37/45]: FAILED linaro-aarch64 [38/45]: FAILED linaro-arm [39/45]: FAILED sourcery-arm-armv4t [40/45]: FAILED sourcery-arm [41/45]: FAILED sourcery-arm-thumb2 [42/45]: FAILED sourcery-mips64 [43/45]: FAILED sourcery-mips [44/45]: FAILED sourcery-nios2 [45/45]: FAILED 45 builds, 4 skipped, 23 build failed, 0 legal-info failed The reason is that CMake doesn't link executables and so-libraries with the pthread library and doesn't use the '-pthread' flag either. Digging a little deeper, I saw that the build always breaks when the code of pthread's functions is in the separate library, i.e. when the libpthread should be linked explicitly. I observe this behavior with cmake 3.17.4 on Fedora 32 and with cmake 3.16.3 on Ubuntu 20.04. At the same time, I am sure that everything is correct in my CMakefiles. In particular, when building locally for a host system, I see the `-pthread` flag in the linking commands (or linking with a libpthread on the other host). -- I looked at support/misc/toolchainfile.cmake.in and package/pkg-cmake.mk but I didn't notice any errors. As a workaround, I temporarily added a patch to my package that forcibly adds the `-pthread` flag for linking executables and so-libraries. https://github.com/erthink/libmdbx/commit/787eaaa373073e17f3a53658b085c255bc2c8ff8
Can you attach your patch that adds libmdbx package (i.e. Config.in, libmdbx.mk and libmdbx.hash)?
Created attachment 8601 [details] patch with libmdbx package as a testcase Basically this is identical to patch with libmdbx-package submission, but WITHOUT workaround for https://bugs.busybox.net/show_bug.cgi?id=13241 So it could be used as a testcase.
I build-tested v4 (i.e. https://patchwork.ozlabs.org/project/buildroot/patch/20201006192709.8265-2-leo@yuriev.ru/mbox/) and every configuration is building fine with cmake 3.18.2. I also tried to build test it with host-cmake (i.e cmake 3.15.5) and it also seems to build fine so I don't know if there is anything that could be done on buildroot side. You can send a v5 with your workaround or we can also wait to see if there is any autobuilder failures after v4 is merged.
(In reply to Fabrice Fontaine from comment #3) Minor clarification: - v4 of the my package-submission patch already includes a workaround for this bug. So it is expected to build it with CMake >= 3.8 successfully with buildroot or on a host. - To reproduce the problem, remove the corresponding patch from the libmdbx package, or use the patch attached (#8601) above without workaround. - v4 passes review and libmdbx' mainstream already contain a workaround for this bug. So I don't suppose to ship v5 until the next release of libmdbx or until some bug affecting buildroot users or builds was fixed.
Thank you for your report. The issue tracker for the Buildroot project has been moved to the Gitlab.com issue tracker: https://gitlab.com/buildroot.org/buildroot/-/issues We are taking this opportunity to close old issues in this old tracker. If you believe your issue is still relevant, please open one in the new issue tracker. Thank you!