I'm building the fsl-toolchain and installing the toolset on another machine of the exact same architecture but I've noticed that the cross-platfrom tools (e.g: powerpc64-fsl-linux-gcc) only works on the host where it was built.
The reason is that when it is installed on another machine it can't find the "interpreter".
powerpc64-fsl-linux-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /mnt/opt/dunfell/build_t4240rdb-64b/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=82ab6faa07be5cfbc02aee1b1ea6a488c154a728, stripped
I noticed that the dynamic reference for the shared object has the fully qualified name:
ldd powerpc64-fsl-linux-gcc
linux-vdso.so.1 (0x00007ffd2d738000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1654d39000)
/mnt/opt/dunfell/build_t4240rdb-64b/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f165512a000)
That was not the case from older SDK versions (I verified it with 2.0) where the dynamic link symbol didn't have the absolute path built-in.
As a workaround, I used the patchelf tool to set the interpreter to a non-absolute path:
patchelf --set-interpreter /lib64/ld-linux-x86-64.so.2 powerpc64-fsl-linux-gcc
After that:
ldd powerpc64-fsl-linux-gcc
linux-vdso.so.1 (0x00007ffdecbb4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb933e42000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb934233000)
Then, the powerpc64-fsl-linux-gcc can be installed and executed on the other host, where such absolute path doesn't exist.
I found that in ./poky/meta/classes/uninative.bbclass something similar as my workaround is done but is not creating the dynamic links that I expect.
Is there a any configuration option to specify the interpreter link name?
Thanks.