Hi Kevin, this might be better posted to the OpenADK mailinglist.
> 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. ;) > Do you have a OpenADK .config to check? But I think you might be right that you should build gcc with shared libraries supported. best regards Waldemar _______________________________________________ devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-le...@uclibc-ng.org
