cross compilation with sdk failing in aarch64-linux-gnu-ar

[jjccar]

Hello,

I created an image and a sdk from the branch stable/v01.03 running on my pc with Ubuntu 20.04.1.

I trying to compile a C++ project, using the cross compilation toolchain from the SDK, but I am having errors while using aarch64-linux-gnu-ar.

I setup my CMake to look for the sysroot at SDK folder and to look for proper g++ compiler on the same folder:

SET(CMAKE_SYSROOT "personal_path/siemens-meta-iot2050-stable-v1.03_images/sdk-iot2050-debian-arm64") set(TOOL_CHAIN_PATH "${CMAKE_SYSROOT}/usr/bin") set(CMAKE_C_COMPILER ${TOOL_CHAIN_PATH}/aarch64-linux-gnu-gcc) set(CMAKE_CXX_COMPILER ${TOOL_CHAIN_PATH}/aarch64-linux-gnu-g++)

When I start the compilation, the first library on the build is the googletest, it builds but it fails the ar step:

personal_path/iot2050/siemens-meta-iot2050-stable-v1.03_images/sdk-iot2050-debian-arm64/usr/bin/aarch64-linux-gnu-ar qc ../../../lib/libgtest.a "CMakeFiles/gtest.dir/src/gtest-all.cc.o" Error running link command: Segmentation fault

If I try to run the above command, directly from the console, I get the same error, so it is not a problem of the build system.

2. In the meantime I tried to compile my project using the example SDK provided at : https://support.industry.siemens.com/cs/document/109741799/downloads-for-simatic-iot20x0?dti=0&lc=en-WW

If I use the IOT2050_SDK_Linux_V1.2.2.zip

I get exactly the same error.

If I use the IOT2050_SDK_Linux_V1.1.1.zip

I am able to build my project without any errors.

3. In another attempt to debug this problem I installed on my ubuntu host the toolchain : gcc-10-aarch64-linux-gnu version (10.3.0-1ubuntu1~20.04cross1) with apt-get

If I change my cmake to use the ar command from my local toolchain, I am able to compile as well

SET(CMAKE_SYSROOT "personal_path/siemens-meta-iot2050-stable-v1.03_images/sdk-iot2050-debian-arm64") set(TOOL_CHAIN_PATH "${CMAKE_SYSROOT}/usr/bin") set(CMAKE_AR /usr/bin/aarch64-linux-gnu-ar) set(CMAKE_RANLIB /usr/bin/aarch64-linux-gnu-ranlib) set(CMAKE_C_COMPILER ${TOOL_CHAIN_PATH}/aarch64-linux-gnu-gcc) set(CMAKE_CXX_COMPILER ${TOOL_CHAIN_PATH}/aarch64-linux-gnu-g++)

This is pointing me to a problem on the aarch64-linux-gnu-ar contained in the SDK.

4. If I run the command on the command line with the help of gdb I got this backtrace:

Program received signal SIGSEGV, Segmentation fault.

`0x00007ffff7c8a40c in __dlopen (mode=2, file=0x555555569480 "personal_path/siemens-meta-iot2050-stable-v1.03_images/sdk-iot2050-debian-arm64/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so") at dlopen.c:78 78 dlopen.c: No such file or directory. (gdb) backtrace

0 0x00007ffff7c8a40c in __dlopen (mode=2,

file=0x555555569480 "personal_path/siemens-meta-iot2050-stable-v1.03_images/sdk-iot2050-debian-arm64/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so") at dlopen.c:78

1 __dlopen (file=0x555555569480 "personal_path/siemens-meta-iot2050-stable-v1.03_images/sdk-iot2050-debian-arm64/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so",

mode=2) at dlopen.c:74

2 0x00007ffff7f617fd in ?? () from personal_path/siemens-meta-iot2050-stable-v1.03_images/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libbfd-2.35.2-arm64.so

3 0x00007ffff7f61b29 in ?? () from personal_path/siemens-meta-iot2050-stable-v1.03_images/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libbfd-2.35.2-arm64.so

4 0x00007ffff7ee2b1a in bfd_check_format_matches ()

from personal_path/siemens-meta-iot2050-stable-v1.03_images/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libbfd-2.35.2-arm64.so

5 0x00007ffff7edbec8 in ?? () from personal_path/siemens-meta-iot2050-stable-v1.03_images/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libbfd-2.35.2-arm64.so

6 0x00007ffff7ee9dea in bfd_close () from personal_path/siemens-meta-iot2050-stable-v1.03_images/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libbfd-2.35.2-arm64.so

7 0x0000555555559496 in ?? ()

8 0x000055555555722a in ?? ()

9 0x00007ffff7ce8d0a in __libc_start_main () from personal_path/siemens-meta-iot2050-stable-v1.02_images/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libc.so.6

10 0x00005555555573aa in ?? ()`

The file ....../liblto_plugin.so does exist

objdump -f personal_path/siemens-meta-iot2050-stable-v1.03_images/sdk-iot2050-debian-arm64/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so

gives :

liblto_plugin.so: file format elf64-x86-64 architecture: i386:x86-64, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x00000000000046e

Can you please help me with this question, or provide any standard alternative to the SDK ?

Thank you in advance.

[jjccar]

Hello,

After some more investigation I found out the origin of the problem :

Going to the IOT2050_SDK_Linux_V1.1.1 after a successful ./relocate.sh, the output of ldd personal_path/IOT2050_SDK_Linux_V1.1.1/sdk-iot2050-debian-arm64/usr/bin/aarch64-linux-gnu-ar is

linux-vdso.so.1 (0x00007ffdb87d8000)
libbfd-2.31.1-arm64.so => personal_path/IOT2050_SDK_Linux_V1.1.1/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libbfd-2.31.1-arm64.so (0x00007f90fe11f000)
libz.so.1 => personal_path/IOT2050_SDK_Linux_V1.1.1/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007f90fdf01000)
libdl.so.2 => personal_path/IOT2050_SDK_Linux_V1.1.1/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libdl.so.2 (0x00007f90fdefc000)
libc.so.6 => personal_path/IOT2050_SDK_Linux_V1.1.1/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f90fdd3b000)
personal_path/IOT2050_SDK_Linux_V1.1.1/sdk-iot2050-debian-arm64/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f90fe261000)

Going to the IOT2050_SDK_Linux_V1.2.2 after a successful ./relocate.sh, the output of

ldd personal_path/IOT2050_SDK_Linux_V1.1.1/sdk-iot2050-debian-arm64/usr/bin/aarch64-linux-gnu-ar is

linux-vdso.so.1 (0x00007ffc1fffa000)
libbfd-2.35.2-arm64.so => personal_path/IOT2050_SDK_Linux_V1.2.2/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libbfd-2.35.2-arm64.so (0x00007f1061e6e000)
libc.so.6 => personal_path/IOT2050_SDK_Linux_V1.2.2/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f1061ca9000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1061c73000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1061c6d000)
personal_path/IOT2050_SDK_Linux_V1.2.2/sdk-iot2050-debian-arm64/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f1061fb2000)

The segmentation fault occurs, in this case, because the command looks for libz.so.1 libdl.so.2 outside the sysroot.

The solution I found was to patchelf the aarch64-linux-gnu-ar and aarch64-linux-gnu-ranlib with the proper path to these libraries

cd personal_path/IOT2050_SDK_Linux_V1.2.2/sdk-iot2050-debian-arm64/

patchelf usr/bin/aarch64-linux-gnu-ar --add-needed personal_path/IOT2050_SDK_Linux_V1.2.2/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libz.so.1

patchelf usr/bin/aarch64-linux-gnu-ar --add-needed personal_path/IOT2050_SDK_Linux_V1.2.2/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libdl.so.2 

patchelf usr/bin/aarch64-linux-gnu-ranlib --add-needed personal_path/IOT2050_SDK_Linux_V1.2.2/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libz.so.1

patchelf usr/bin/aarch64-linux-gnu-ranlib --add-needed personal_path/IOT2050_SDK_Linux_V1.2.2/sdk-iot2050-debian-arm64/usr/lib/x86_64-linux-gnu/libdl.so.2 

With this patches I was able to build my project.

Could this be related by some failing steps during the ./relocate.sh ?

Thanks

[jan-kiszka]

Let me reproduce... The script is coming from Isar, but it may be not fully tested regularly, neither there nor here.

[jan-kiszka]

Meanwhile, you could also use the container image that is produced along the tarball. That one does not need relocation as it runs a complete Debian rootfs. See README for how to import that image.

[jjccar]

Hello,

Thank you for the info.

[jan-kiszka]

Using also --force-rpath in the patchelf command of relocate.sh seems to do the trick. Can you confirm that?

patchelf --set-interpreter ${new_sdkroot}${interpreter} \
        --set-rpath ${new_sdkroot}/usr/lib:${new_sdkroot}/usr/lib/${arch}-linux-gnu \
        --force-rpath \
        $binary 2>/dev/null

[jjccar]

It works.

The ticket can be closed.

Thank you

[jan-kiszka]

Formally only once the fix is merged here. Upstream patch is pending now: https://groups.google.com/g/isar-users/c/3dKmvz6GufA

[jan-kiszka]

Merged now.