On Thu, May 2, 2024 at 9:53 AM Waldemar Brodkorb
<wbx(a)openadk.org> wrote:
On Thu,
May 2, 2024 at 7:13 AM Waldemar Brodkorb <wbx(a)openadk.org> wrote:
Okay, I
switched to dc233c with call0 ABI. Now I get a linker issue:
rm -f lib/ld-uClibc.so lib/ld-uClibc.so.1 lib/ld-uClibc-1.0.48.so
/home/wbx/openadk/toolchain_qemu-xtensa_uclibc-ng_dc233c_call0_fdpic_nommu/usr/bin/xtensa-openadk-linux-uclibc-gcc
-Wl,-EL -shared -Wl,--warn-common -Wl,--warn-once -Wl,-z,combreloc
-Wl,-z,relro -Wl,-O2 -Wl,-z,defs
-L/home/wbx/openadk/target_qemu-xtensa_uclibc-ng_dc233c_call0_fdpic_nommu/lib
-L/home/wbx/openadk/target_qemu-xtensa_uclibc-ng_dc233c_call0_fdpic_nommu/usr/lib
-Wl,-O1 -Wl,-rpath -Wl,/usr/lib -Wl,-rpath-link
-Wl,/home/wbx/openadk/target_qemu-xtensa_uclibc-ng_dc233c_call0_fdpic_nommu/usr/lib
-Wl,-e,_start -Wl,-z,now -Wl,-Bsymbolic -Wl,--export-dynamic
-Wl,--sort-common -Wl,--no-undefined -Wl,--discard-locals -Wl,--dis
card-all -Wl,-soname=ld-uClibc.so.1 -nostdlib -nostartfiles -o
lib/ld-uClibc-1.0.48.so -Wl,--whole-archive
ldso/ldso/ld-uClibc_so.a -Wl,--no-whole-archive -shared
/home/wbx/openadk/toolchain_qemu-xtensa_uclibc
-ng_dc233c_call0_fdpic_nommu/usr/lib/gcc/xtensa-openadk-linux-uclibc/14.0.1/libgcc.a
/home/wbx/openadk/toolchain_qemu-xtensa_uclibc-ng_dc233c_call0_fdpic_nommu/usr/lib/gcc/xtensa-openadk-linux-uclibc/14.0.1/../../../../xtensa-openadk-linux-uclibc/bin/ld:
ldso/ldso/ld-uClibc_so.a(ldso.oS): unexpected FDPIC-specific relocation
/home/wbx/openadk/toolchain_qemu-xtensa_uclibc-ng_dc233c_call0_fdpic_nommu/usr/lib/gcc/xtensa-openadk-linux-uclibc/14.0.1/../../../../xtensa-openadk-linux-uclibc/bin/ld:
ldso/ldso/ld-uClibc_so.a(ldso.oS): unexpected FDPIC-specific relocation
What does unexpected FDPIC-specific relocation means?
It means an attempt to link code with FDPIC relocations into a
non-FDPIC output. It seems that you configured the toolchain for
the xtensa-linux-uclibc, for that triplet -mfdpic option is required
both at compilation and at linking steps. If you configure for
xtensa-linux-uclibcfdpic the linker will be producing FDPIC
output by default.
FWIW I have ct-ng branch that I used to build reference toolchain here:
I am still using the overlay method for
binutils/gcc and Linux.
It should still work and the result should be the same.