Build/Run 32bit application on Tx2

I am trying to build and run a 32bit application on the Tx2.
The libraries I need to use are complied for 32bit for Tx1. I was able to use arm-linux-gnueabihf-gcc and arm-linux-gnueabihf-g++ to successful compile the source code and link to the the 32bit libraries but I still am unable to run the built binary. All of this has been done on the Tx2 device, not on an external host.

I followed the suggestions in this thread to get to where I am now.

Is what im attempting even possible; build and link 32bit libraries to produce 32bit binary and run it on the tx2?

Is there something I can enable and rebuild the kernel that will allow 32bit applications to run?

Here is the library

nvidia@tegra-ubuntu:~/DUOSDK/SDK/linux/arm$ file ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=efb9534c40dad70bffd8e0e0a8b7b3cf276ee3aa, stripped

This is the final complied binary:

nvidia@tegra-ubuntu:~/DUOSDK/Samples/C++/bin/arm$ file Sample-01-Motion 
Sample-01-Motion: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 3.2.0, BuildID[sha1]=056d82c7d43dede5a0ec257ce39bc0acef932d7d, not stripped

These are some other configuration on the Tx2

sudo apt-get install g++-4.8-arm-linux-gnueabihf gcc-4.8-arm-linux-gnueabihf`
export CC=/usr/bin/arm-linux-gnueabihf-gcc`
export CXX=/usr/bin/arm-linux-gnueabihf-g++`

ADD to CMakeLists.txt

#Set the RPATH to be used when installing
SET(CMAKE_INSTALL_RPATH "/usr/arm-linux-gnueabihf/")

and create arm-linux-gnueabi.conf inside /etc/

# Multiarch support

When i try and run the binary i get.

nvidia@tegra-ubuntu:~/DUOSDK/Samples/C++/bin/arm$ ls
Sample-01-Motion  Sample-03-Parameters  Sample-05-Polling
Sample-02-Images  Sample-04-Sequences
nvidia@tegra-ubuntu:~/DUOSDK/Samples/C++/bin/arm$ ./Sample-01-Motion 
-bash: ./Sample-01-Motion: No such file or directory

The CPU is able to execute armhf, but there are some catches to this.

Within the kernel the kernel mode is normally arm64 (ARMv8-a). Given the correct interrupt, the CPU will switch to arm32 (ARMv8…basically a combination of armhf+NEON being supported) and run the armhf, but it isn’t possible to run both at the same time. arm64 is the “native” mode/architecture, arm32 is a “foreign” mode/architecture. The kernel support is likely not the problem.

In user space there are combinations of libraries and the linker which support almost any non-trivial program, e.g., even a “hello world” type application links to libc. The very first R23.x releases supported only the arm32 user space. Starting in R24.1 arm64 64-bit user space was supported. As currently used you will have only the native arm64 user space. You could add armhf as a “foreign architecture” by adding the armhf linker and all required libraries in their 32-bit form, but this is very invasive and requires a lot of additions.

I have not tried to do this, in part because of the complexity and in part because performance would be dismal while doubling the disk space for user space support. If you want to do this though what you would need to research is adding a foreign architecture to the apt/apt-get package tools so that not only is arm64 shown when searching for a package, armhf would also show up. Then you would add an armhf version of the linker, libc, and anything which your application might want to link against.

Keep in mind that armhf support for CUDA stops at something like version 6.5. You cannot get newer CUDA support under armhf…versions newer than 6.5 require 64-bit.