[openadk] Re: [uclibc-ng-devel] Target GCC compiled via OpenADK can't find dl_iterate_phdr

Hello there! Apologies if this is going into the wrong list, but I honestly was n't sure,e specially since this very issue was discussed a long time ago - found an exchange about this in the archive through Google - so I ended up just posting it here. I am currently building a toolset for RISC-V to use as a rootfs for a Docker Container that can then be used as a Jenkins agent to eventually build my way through Alpine's abuild/aports, so that I can reconstruct the alpine:3.19 image, but for RISC-V (there are only snapshots and the :edge image, right now). Most things built just fine; kernel, toolchain and alike. But when it tries to configure libatomic for the target, this happens: configure:14906: riscv64-openadk-linux-uclibc-cc     -o conftest -g -O2  -g -Os -fno-sync-libcalls  -pthread   conftest.c  >&5/nvme/opt/openadk/toolchain_generic-riscv64_uclibc-ng/usr/lib/gcc/riscv64-openadk-linux-uclibc/13.2.0/../../../../riscv64-openadk-linux-uclibc/bin/ld: /nvme/opt/openadk/toolchain_generic-riscv64_uclibc-ng/usr/lib/gcc/riscv64-openadk-linux-uclibc/13.2.0/libgcc.a(unwind-dw2-fde-dip.o): in function `_Unwind_Find_FDE': (.text+0x1adc): undefined reference to `dl_iterate_phdr' configure:14925: error: Pthreads are required to build libatomic I went and looked up what that function is, exactly, and learned quickly that this is caused by me having chosen a static build. That said, this was also already discussed: https://uclibc.uclibc.narkive.com/079V4ltx/dl-iterate-phdr-missing-in-libc So, I am at a loss on what to do right now. I changed my setting to also build dynamic objects, then cleaned uClibc-ng and rebuilt and then attempted again to let the normal build run. But, that too, did not help. My questions: - Is dl_iterate_phdr in libc.a? According to grep, it matches, but that doesn-ät mean much. - I am using the 1.0.46 version of uClibc as openADK selects that. - Is there anything I can do to fix this, or do I have to start over and just build with shared libraries? I honestly would not be surprised if GCC just didn#t want to be statically linked; static is the devil, after all. ;)