ldd on copied .so files are outputting "not a dynamic executable"

Robotics & Edge Computing Jetson Systems Jetson TX2
1

When doing a make on on a cloned repo, all of the .so files copied from an x86 server were being flagged as “skipping incompatible” resulting in a failed make. I compared the ldd output of the same .so files in the x86 server to the Jetson. On the x86 server the ldd output looks normal, on the Jetson I get “not a dynamic excutable”. File size remained the same after the scp-ing over to the Jetson. Any idea why this happens? Thanks in advance.

x86 server:
$ldd libbgr2lab.so
linux-vdso.so.1 => (0x00007ffc78fee000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe360c12000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe360909000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe3606f3000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe360328000)
/lib64/ld-linux-x86-64.so.2 (0x00005609572ef000)

Jetson tx2:
$ldd libbgr2lab.so
not a dynamic executable

2

What does “file libbgr2lab.so” show? Probably one of the biggest problems would be if part of the x86_64 environment was linked in. I’ve also seen files indirectly downloaded over wget actually be the HTML web page…but named with “.so”. It’s hard to say from the above.

3

nvidia@tegra-ubuntu:~$ file libbgr2lab.so
libbgr2lab.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped

nvidia@tegra-ubuntu:~$ objdump -i libbgr2lab.so
BFD header file version (GNU Binutils for Ubuntu) 2.26.1
elf64-littleaarch64
(header little endian, data little endian)
aarch64
elf64-bigaarch64
(header big endian, data big endian)
aarch64
elf32-littleaarch64
(header little endian, data little endian)
aarch64
elf32-bigaarch64
(header big endian, data big endian)
aarch64
elf32-littlearm
(header little endian, data little endian)
arm
elf32-bigarm
(header big endian, data big endian)
arm
elf64-little
(header little endian, data little endian)
plugin
arm
aarch64
elf64-big
(header big endian, data big endian)
plugin
arm
aarch64
elf32-little
(header little endian, data little endian)
plugin
arm
aarch64
elf32-big
(header big endian, data big endian)
plugin
arm
aarch64
plugin
(header little endian, data little endian)
srec
(header endianness unknown, data endianness unknown)
plugin
arm
aarch64
symbolsrec
(header endianness unknown, data endianness unknown)
plugin
arm
aarch64
verilog
(header endianness unknown, data endianness unknown)
plugin
arm
aarch64
tekhex
(header endianness unknown, data endianness unknown)
plugin
arm
aarch64
binary
(header endianness unknown, data endianness unknown)
plugin
arm
aarch64
ihex
(header endianness unknown, data endianness unknown)
plugin
arm
aarch64

           elf64-littleaarch64 elf64-bigaarch64 elf32-littleaarch64 
    plugin ------------------- ---------------- ------------------- 
       arm ------------------- ---------------- ------------------- 
   aarch64 elf64-littleaarch64 elf64-bigaarch64 elf32-littleaarch64 

           elf32-bigaarch64 elf32-littlearm elf32-bigarm elf64-little 
    plugin ---------------- --------------- ------------ elf64-little 
       arm ---------------- elf32-littlearm elf32-bigarm elf64-little 
   aarch64 elf32-bigaarch64 --------------- ------------ elf64-little 

           elf64-big elf32-little elf32-big plugin srec symbolsrec verilog 
    plugin elf64-big elf32-little elf32-big ------ srec symbolsrec verilog 
       arm elf64-big elf32-little elf32-big ------ srec symbolsrec verilog 
   aarch64 elf64-big elf32-little elf32-big ------ srec symbolsrec verilog 

           tekhex binary ihex 
    plugin tekhex binary ihex 
       arm tekhex binary ihex 
   aarch64 tekhex binary ihex
4

Here’s the problem (excerpt from the “file” command):

x86-64

…this is for a desktop PC, not arm64/aarch64. It needs to be created with the cross-architecture tools if building from a PC…and anything linked against needs to be arm64/aarch64. A Jetson won’t recognize this…x86-64 is a foreign architecture when a Jetson sees it, arm64 is a foreign architecture when a PC sees it. I’m not sure what all of the other output is, but “file” should not have seen x86-64.

5

Thanks! We inherited this repo with the .so files already packaged. Would you happen to know of any sources for these libs compiled for arm64/aarch64?

libbgr2lab.so
libattribute_analysis.so
libsecurec.so

6

I didn’t see any of those from apt search. If they are available in source form you may be in luck. One thought on this though is that “libsecurec.s” sounds like a security modified libc…if this is the case it probably has x86_64 assembler or other architecture-dependent code in it…in which case not only would the source code be required, porting to this architecture would also be required (not everything in x86_64 applies in arm64, especially security issues).