Drive 10 sample cross compiling compilation error

klaus.kofler · February 14, 2020, 10:42am

I was trying to cross compile the driveworks-2.2 samples on my PC. I followed the steps on https://docs.nvidia.com/driveworks/dwx_samples_building_V5L.html. However, when I call make, I get the following compilation error:

Scanning dependencies of target update_cuda_deps
Scanning dependencies of target lodepng-src
Scanning dependencies of target samples_allocator
[  0%] Building CXX object 3rdparty/src/lodepng/CMakeFiles/lodepng-src.dir/src/lodepng.cpp.o
[  0%] Dependencies for /home/drive10/samplesNvidia/src/imageprocessing/stereo/stereo/CMakeFiles/sample_stereo_disparity.dir//gen_utils.cu.o.depend.stamp
[  0%] Dependencies for /home/drive10/samplesNvidia/src/imageprocessing/motion/denseopticalflow/CMakeFiles/sample_denseopticalflow.dir//gen_utils.cu.o.depend.stamp
[  2%] Dependencies for /home/drive10/samplesNvidia/src/imageprocessing/stereo/stereoPVA/CMakeFiles/sample_stereo_disparity_pva.dir//gen_utils.cu.o.depend.stamp
[  2%] Dependencies for /home/drive10/samplesNvidia/src/image/image_common/CMakeFiles/dw_samples_image_common.dir//gen_utils.cu.o.depend.stamp
[  2%] Building CXX object src/framework/CMakeFiles/samples_allocator.dir/Allocator.cpp.o
Scanning dependencies of target glfw-x11
[  2%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/x11_init.c.o
In file included from /usr/local/driveworks-2.2/samples/3rdparty/src/lodepng/include/lodepng.h:29:0,
                 from /usr/local/driveworks-2.2/samples/3rdparty/src/lodepng/src/lodepng.cpp:31:
/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/string.h:41:1: error: ‘__BEGIN_NAMESPACE_STD’ does not name a type; did you mean ‘__BEGIN_DECLS’?
 __BEGIN_NAMESPACE_STD
 ^~~~~~~~~~~~~~~~~~~~~
 __BEGIN_DECLS
[  3%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/egl_context.c.o
[  3%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/posix_time.c.o
[  3%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/input.c.o
[  3%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/glx_context.c.o
[  3%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/context.c.o
[  5%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/x11_window.c.o
[  5%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/window.c.o
/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/string.h:49:1: error: ‘__END_NAMESPACE_STD’ does not name a type
 __END_NAMESPACE_STD
 ^~~~~~~~~~~~~~~~~~~
[  6%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/init.c.o
[  7%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/x11_monitor.c.o
[  7%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/linux_joystick.c.o
[  7%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/vulkan.c.o
In file included from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/wchar.h:37:0,
                 from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/include/c++/7.3.1/cwchar:44,
                 from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/include/c++/7.3.1/bits/postypes.h:40,
                 from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/include/c++/7.3.1/iosfwd:40,
                 from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/include/c++/7.3.1/memory:72,
                 from /usr/local/driveworks-2.2/samples/src/framework/Allocator.cpp:32:
/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/stdio.h:47:1: error: ‘__BEGIN_NAMESPACE_STD’ does not name a type; did you mean ‘__BEGIN_DECLS’?
 __BEGIN_NAMESPACE_STD
 ^~~~~~~~~~~~~~~~~~~~~
 __BEGIN_DECLS
[  8%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/posix_tls.c.o
/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/stdio.h:50:1: error: ‘__END_NAMESPACE_STD’ does not name a type
 __END_NAMESPACE_STD
 ^~~~~~~~~~~~~~~~~~~
/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/string.h:61:1: error: ‘__BEGIN_NAMESPACE_STD’ does not name a type; did you mean ‘__BEGIN_DECLS’?
 __BEGIN_NAMESPACE_STD
 ^~~~~~~~~~~~~~~~~~~~~
 __BEGIN_DECLS
[  9%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/monitor.c.o
In file included from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/include/c++/7.3.1/cwchar:44:0,
                 from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/include/c++/7.3.1/bits/postypes.h:40,
                 from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/include/c++/7.3.1/iosfwd:40,
                 from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/include/c++/7.3.1/memory:72,
                 from /usr/local/driveworks-2.2/samples/src/framework/Allocator.cpp:32:
/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/wchar.h:105:1: error: ‘__BEGIN_NAMESPACE_C99’ does not name a type; did you mean ‘_GLIBCXX_NAMESPACE_CXX11’?
 __BEGIN_NAMESPACE_C99
 ^~~~~~~~~~~~~~~~~~~~~
 _GLIBCXX_NAMESPACE_CXX11
/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/string.h:96:1: error: ‘__END_NAMESPACE_STD’ does not name a type
 __END_NAMESPACE_STD
 ^~~~~~~~~~~~~~~~~~~
In file included from /usr/local/driveworks-2.2/samples/3rdparty/src/glfw/3.2-screen/src/x11_platform.h:32:0,
                 from /usr/local/driveworks-2.2/samples/3rdparty/src/glfw/3.2-screen/src/internal.h:163,
                 from /usr/local/driveworks-2.2/samples/3rdparty/src/glfw/3.2-screen/src/x11_init.c:28:
/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/signal.h:40:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘typedef’
 typedef __sig_atomic_t sig_atomic_t;
 ^~~~~~~
/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/signal.h:49:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘typedef’
...

These and similar error continue for a total of over 100,000 lines.

The PC has a fresh installation of Ubuntu 18.04 LTS as well as the installation of Nvidia Drive Software 10.0 on it. I used this PC to flash Drive Software 10.0 to the DriveAGX, which did work fine. Also, our own program runs on the DriveAGX when cross compiled on that PC. Does anybody hava an idea what went wrong there?

VickNV · February 14, 2020, 3:19pm

Hi klaus.kofler,

Please check if any failed messages in running your cmake command, e.g.

$ cmake -DCMAKE_BUILD_TYPE=Release
-DCMAKE_TOOLCHAIN_FILE=/path/to/driveworks/samples/cmake/Toolchain-V5L.cmake
-DVIBRANTE_PDK:STRING=/path/to/drive-t186ref-linux
/path/to/driveworks/samples/folder

Thanks!

klaus.kofler · February 14, 2020, 3:30pm

I used the following CMake command:

cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=/usr/local/driveworks-2.2/samples/cmake/Toolchain-V5L.cmake -DVIBRANTE_PDK:STRING=/usr/local/drive/drive-t186ref-linux /usr/local/driveworks-2.2/samples/

The output looks as follows:

-- VIBRANTE_PDK = /usr/local/drive/drive-t186ref-linux
-- VIBRANTE_PDK_DEVICE = t186ref
-- VIBRANTE_PDK_BRANCH = 5.1.6.1
-- Vibrante version 5.1.6.1
-- VIBRANTE_PDK = /usr/local/drive/drive-t186ref-linux
-- Vibrante version 5.1.6.1
-- The C compiler identification is GNU 7.3.1
-- The CXX compiler identification is GNU 7.3.1
-- Check for working C compiler: /usr/local/drive/drive-t186ref-linux/../toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc
-- Check for working C compiler: /usr/local/drive/drive-t186ref-linux/../toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/local/drive/drive-t186ref-linux/../toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-g++
-- Check for working CXX compiler: /usr/local/drive/drive-t186ref-linux/../toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found CUDA: /usr/local/cuda (found version "10.2") 
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1") 
-- Found EGL: /usr/local/drive/drive-t186ref-linux/lib-target/libEGL.so  
-- Found /usr/local/drive/drive-t186ref-linux/lib-target/libEGL.so:
--  - Includes: [/usr/local/drive/drive-t186ref-linux/include]
--  - Libraries: [/usr/local/drive/drive-t186ref-linux/lib-target/libEGL.so]
-- Found: /usr/local/drive/drive-t186ref-linux/lib-target/libdrm.so
-- Header at: /usr/local/drive/drive-t186ref-linux/include
-- DW_EXPERIMENTAL_FORCE_EGL set and EGL Support Enabled
-- Cross Compiling for Vibrante
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Default - Building with TRT version 5.1.4.2 and cudnn version 7.5.1.14
-- Building GLFW for X11 (static)
-- Looking for XOpenDisplay in /usr/local/drive/drive-t186ref-linux/lib-target/libX11.so;/usr/local/drive/drive-t186ref-linux/lib-target/libXext.so
-- Looking for XOpenDisplay in /usr/local/drive/drive-t186ref-linux/lib-target/libX11.so;/usr/local/drive/drive-t186ref-linux/lib-target/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Found X11: /usr/local/drive/drive-t186ref-linux/lib-target/libX11.so
-- VIBRANTE_PDK_BRANCH = 5.1.6.1
-- Found vibrante lib: /usr/local/driveworks-2.2/samples/3rdparty/linux-aarch64/vibrante/lib/libudev.so
-- Found vibrante lib: /usr/local/driveworks-2.2/samples/3rdparty/linux-aarch64/vibrante/lib/libusb-1.0.so
-- Found vibrante_Xlib: /usr/local/driveworks-2.2/samples/3rdparty/linux-aarch64/vibrante_Xlibs/lib/libXcursor.so
-- Driveworks Samples install dir: /home/drive10/samplesNvidia/install
-- Cross Compiling for Vibrante
-- Driveworks found at: /usr/local/driveworks-2.2/targets/aarch64-Linux
-- Found Driveworks 
-- Configuring done
-- Generating done
-- Build files have been written to: /home/drive10/samplesNvidia

I cannot spot any error message there.

VickNV · February 14, 2020, 4:49pm

Yeah, it looks all normal.

I haven’t seen this issue before. But why is your path “/usr/local/drive” instead of “/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS”?
Could you try if changing it helps?

klaus.kofler · February 17, 2020, 10:02am

“/usr/local/drive” is a symlink to “/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS”. It was automatically created for some version of the drive software and we like to keep it, i. e. generate it manually for a user independent setup. However, changing the path to “/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS” did not change anything.

I looked at the error in a bit more detail and found out that the Drive Software 10 comes with their own cross-compiling gcc (gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu) while also installing a system wide cross-compiling gcc using apt (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1 in my case). The file Toolchain-V5L.cmake specifies to use the gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu from the DriveOS folder. The problem seems to be, that the include path “/usr/include/aarch64” is added to the compilation of glfw (and maybe also other targets, I haven’t checked that). This leads to the usage of the header file “/usr/include/aarch64-linux-gnu/sys/cdefs.h” (which does not define __BEGIN_NAMESPACE_STD) instead of the header file “/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/sys/cdefs.h” (which does define __BEGIN_NAMESPACE_STD).

This leads me to two questions:

Why does the setup of the Driveworks samples use the include path “/usr/include/aarch64” and how can this be changed?
Why is there a aarch64-linux-gnu-gcc installation in the DriveOS, in addition to the one installed in “/usr/bin”? Should I try using the aarch64-linux-gnu-gcc 7.4.0 from “/usr/bin”?

VickNV · February 18, 2020, 3:56pm

I have no idea why you hit the issue. I haven’t seen anyone hitting this issue.

Then you can try if temporarily removing /usr/include/aarch64-linux-gnu/sys/cdefs.h helps on this issue. I think some environment variable values on your host cause this issue.

klaus.kofler · February 18, 2020, 5:10pm

What environment variable could that be? What environment variables are used by this project? Can somebody actually confirm that the folder “/usr/include/aarch64” is not used in their setup, e. g. by checking if the path appears in the file “3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/flags.make” in the build directory?

Removing “/usr/include/aarch64-linux-gnu/sys/cdefs.h” results in the following errors:

[  8%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/xkb_unicode.c.o
In file included from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/pthread.h:23:0,
                 from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/include/c++/7.3.1/aarch64-linux-gnu/bits/gthr-default.h:35,
                 from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/include/c++/7.3.1/aarch64-linux-gnu/bits/gthr.h:148,
                 from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/include/c++/7.3.1/ext/atomicity.h:35,
                 from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/include/c++/7.3.1/memory:73,
                 from /usr/local/driveworks-2.2/samples/src/framework/Allocator.cpp:32:
/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/sched.h:120:16: error: ‘cpu_set_t’ does not name a type
          const cpu_set_t *__cpuset) __THROW;
                ^~~~~~~~~
In file included from /usr/include/aarch64-linux-gnu/bits/sigthread.h:27:0,
                 from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/signal.h:361,
                 from /usr/local/driveworks-2.2/samples/3rdparty/src/glfw/3.2-screen/src/x11_platform.h:32,
                 from /usr/local/driveworks-2.2/samples/3rdparty/src/glfw/3.2-screen/src/internal.h:163,
                 from /usr/local/driveworks-2.2/samples/3rdparty/src/glfw/3.2-screen/src/linux_joystick.c:28:
/usr/include/aarch64-linux-gnu/bits/types/__sigset_t.h:8:3: error: conflicting types for ‘__sigset_t’
 } __sigset_t;
   ^~~~~~~~~~
In file included from /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/signal.h:32:0,
                 from /usr/local/driveworks-2.2/samples/3rdparty/src/glfw/3.2-screen/src/x11_platform.h:32,
                 from /usr/local/driveworks-2.2/samples/3rdparty/src/glfw/3.2-screen/src/internal.h:163,
                 from /usr/local/driveworks-2.2/samples/3rdparty/src/glfw/3.2-screen/src/linux_joystick.c:28:
/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/bits/sigset.h:30:5: note: previous declaration of ‘__sigset_t’ was here
   } __sigset_t;
     ^~~~~~~~~~
....

Removing the entire “/usr/include/aarch64-linux-gnu” folder gives me several repetitions of the following errors:

[  9%] Building C object 3rdparty/src/glfw/CMakeFiles/glfw-x11.dir/3.2-screen/src/linux_joystick.c.o
In file included from /usr/local/driveworks-2.2/targets/aarch64-Linux/include/dw/core/Types.h:68:0,
                 from /usr/local/driveworks-2.2/samples/src/imageprocessing/stereo/stereoPVA/utils.hpp:34,
                 from /usr/local/driveworks-2.2/samples/src/imageprocessing/stereo/stereoPVA/utils.cu:31:
/usr/include/stdint.h:119:0: error: "__INT64_C" redefined [-Werror]
 #  define __INT64_C(c) c ## LL
 
<built-in>: note: this is the location of the previous definition
In file included from /usr/local/driveworks-2.2/targets/aarch64-Linux/include/dw/core/Types.h:68:0,
                 from /usr/local/driveworks-2.2/samples/src/imageprocessing/stereo/stereoPVA/utils.hpp:34,
                 from /usr/local/driveworks-2.2/samples/src/imageprocessing/stereo/stereoPVA/utils.cu:31:
/usr/include/stdint.h:120:0: error: "__UINT64_C" redefined [-Werror]
 #  define __UINT64_C(c) c ## ULL
 
<built-in>: note: this is the location of the previous definition
In file included from /usr/local/driveworks-2.2/targets/aarch64-Linux/include/dw/core/Types.h:68:0,
                 from /usr/local/driveworks-2.2/targets/aarch64-Linux/include/dw/image/Image.h:51,
                 from /usr/local/driveworks-2.2/samples/src/image/image_common/utils.hpp:34,
                 from /usr/local/driveworks-2.2/samples/src/image/image_common/utils.cu:31:
/usr/include/stdint.h:119:0: error: "__INT64_C" redefined [-Werror]
...

I did manage to compile the samples by modifying the toolchain file so it uses the compilers
“/usr/bin/aarch64-gnu-linux-gcc” and “/usr/bin/aarch64-gnu-linux-g++”. This resulted in the following linker error:

../../3rdparty/src/glfw/libglfw-src.a(x11_init.c.o): In function `_glfwCreateCursorX11':
/usr/local/driveworks-2.2/samples/3rdparty/src/glfw/3.2-screen/src/x11_init.c:682: undefined reference to `XcursorImageCreate'
/usr/local/driveworks-2.2/samples/3rdparty/src/glfw/3.2-screen/src/x11_init.c:702: undefined reference to `XcursorImageLoadCursor'
/usr/local/driveworks-2.2/samples/3rdparty/src/glfw/3.2-screen/src/x11_init.c:703: undefined reference to `XcursorImageDestroy'
../../3rdparty/src/glfw/libglfw-src.a(x11_init.c.o):(.debug_addr+0xab8): undefined reference to `XcursorImageCreate'
../../3rdparty/src/glfw/libglfw-src.a(x11_init.c.o):(.debug_addr+0xca0): undefined reference to `XcursorImageDestroy'
../../3rdparty/src/glfw/libglfw-src.a(x11_init.c.o):(.debug_addr+0xd00): undefined reference to `XcursorImageLoadCursor'
collect2: error: ld returned 1 exit status
src/dataspeedBridge/CMakeFiles/sample_dataspeedBridge.dir/build.make:117: recipe for target 'src/dataspeedBridge/sample_dataspeedBridge' failed
make[2]: *** [src/dataspeedBridge/sample_dataspeedBridge] Error 1
CMakeFiles/Makefile2:4474: recipe for target 'src/dataspeedBridge/CMakeFiles/sample_dataspeedBridge.dir/all' failed

I could resolve this one by adding “Xcursor” to the target_link_libraries in “/usr/local/driveworks-2.2/samples/3rdparty/src/glfw/CMakeLists.txt”.

As the samples compile with the aarch64-linux-gnu-gcc that is installed in the system by the SDK Manager, the question still remains why is there another aarch64-linux-gnu-gcc in the “DRIVEOS/toolchains”?

VickNV · February 18, 2020, 8:08pm

These are all file in my /usr/include/aarch64-linux-gnu/. Maybe that’s the difference. FYI.

$ ls -l /usr/include/aarch64-linux-gnu/
total 764
-rw-r–r-- 1 root root 210320 Jul 21 2019 cublas_api.h
-rw-r–r-- 1 root root 33422 Jul 21 2019 cublas.h
-rw-r–r-- 1 root root 45689 Jul 21 2019 cublasLt.h
-rw-r–r-- 1 root root 10262 Jul 21 2019 cublas_v2.h
-rw-r–r-- 1 root root 41039 Jul 21 2019 cublasXt.h
lrwxrwxrwx 1 root root 10 May 2 2019 cudnn.h → cudnn_v7.h
-rw-r–r-- 1 root root 119417 May 2 2019 cudnn_v7.h
-rw-r–r-- 1 root root 18400 Jul 21 2019 nvblas.h
-rw-r–r-- 1 root root 11309 Apr 29 2019 NvCaffeParser.h
-rw-r–r-- 1 root root 197025 Apr 29 2019 NvInfer.h
-rw-r–r-- 1 root root 25461 Apr 29 2019 NvInferPlugin.h
-rw-r–r-- 1 root root 7408 Apr 29 2019 NvOnnxConfig.h
-rw-r–r-- 1 root root 7512 Apr 29 2019 NvOnnxParser.h
-rw-r–r-- 1 root root 2647 Apr 29 2019 NvOnnxParserRuntime.h
-rw-r–r-- 1 root root 8984 Apr 29 2019 NvUffParser.h
-rw-r–r-- 1 root root 7010 Apr 29 2019 NvUtils.h

VickNV · February 18, 2020, 9:07pm

Please try with the attached Toolchain-V5L.cmake and see if helps on your case. Thanks!
Toolchain-V5L.cmake.zip (2.62 KB)

klaus.kofler · February 19, 2020, 2:21pm

My “/usr/include/aarch64-linux-gnu/” folder looks as folloows:

$ ls -l /usr/include/aarch64-linux-gnu/
total 812
-rw-r–r-- 1 root root 4350 Apr 16 2018 a.out.h
drwxr-xr-x 2 root root 4096 Feb 6 15:07 asm
drwxr-xr-x 3 root root 12288 Feb 6 15:07 bits
-rw-r–r-- 1 root root 210320 Mai 3 2019 cublas_api.h
-rw-r–r-- 1 root root 33423 Mai 3 2019 cublas.h
-rw-r–r-- 1 root root 45666 Mai 3 2019 cublasLt.h
-rw-r–r-- 1 root root 10263 Mai 3 2019 cublas_v2.h
-rw-r–r-- 1 root root 41040 Mai 3 2019 cublasXt.h
lrwxrwxrwx 1 root root 10 Mai 3 2019 cudnn.h → cudnn_v7.h
-rw-r–r-- 1 root root 119417 Mai 3 2019 cudnn_v7.h
-rw-r–r-- 1 root root 2687 Apr 16 2018 fpu_control.h
drwxr-xr-x 2 root root 4096 Feb 6 15:07 gnu
-rw-r–r-- 1 root root 4424 Apr 16 2018 ieee754.h
-rw-r–r-- 1 root root 2159 Nov 12 14:09 jconfig.h
-rw-r–r-- 1 root root 18401 Mai 3 2019 nvblas.h
-rw-r–r-- 1 root root 11309 Apr 29 2019 NvCaffeParser.h
-rw-r–r-- 1 root root 197025 Apr 29 2019 NvInfer.h
-rw-r–r-- 1 root root 25461 Apr 29 2019 NvInferPlugin.h
-rw-r–r-- 1 root root 7408 Apr 29 2019 NvOnnxConfig.h
-rw-r–r-- 1 root root 7512 Apr 29 2019 NvOnnxParser.h
-rw-r–r-- 1 root root 2647 Apr 29 2019 NvOnnxParserRuntime.h
-rw-r–r-- 1 root root 8984 Apr 29 2019 NvUffParser.h
-rw-r–r-- 1 root root 7010 Apr 29 2019 NvUtils.h
drwxr-xr-x 2 root root 4096 Feb 18 17:20 sys

If I remove the folders “asm”, “bits”, “gnu”, and “sys” and use the standard Toolchain-V5L.cmake file the samples compile and link without any error.

Using your newly provided Toolchain-V5L.cmake file with the unchanged /usr/include/aarch64-linux-gnu/ folder gives the same error as the original Toolchain-V5L.cmake file. If I remove all the folders that I have in “/usr/include/aarch64-linux-gnu/” and use the modified Toolchain-V5L.cmake i get many warning saying

/home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/7.3.1/../../../../aarch64-linux-gnu/bin/ld: warning: libEGL.so.1, needed by /home/drive10/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/DRIVEOS/drive-t186ref-linux/targetfs_a/usr/local/driveworks-2.2/targets/aarch64-Linux/lib/libnvinfer.so.5, not found (try using -rpath or -rpath-link)

but it does compile and link sucessfully anyways. So it is clearly the existance of the additional inlcude folders in “/usr/include/aarch64” which made the build fail on my system. I don’t know how they ended up there, but NVIDIA should consider to make the build system more robust in that regard.

Looking at the modified Toolchain-V5L.cmake file, I realized that the original Toolchain-V5L.cmake shipped with the samples uses the path ${VIBRANTE_PDK}/targetfs, which is not existant on my system, as it seems to be replaced with ${VIBRANTE_PDK}/targetfs_a and ${VIBRANTE_PDK}/targetfs_b. Considering that the compilation can work with the non-existing path, it seems this path is not needed at all by the build system…

But the question why there is a complete installation of a aarch64-linux-gnu-gcc in the DRIVEOS directory remains. And most of all, which one is recommended to be used for cross compilation our own projects? The one aarch64-linux-gnu-gcc “/usr/bin” installed via apt or the one in the DRIVEOS directory?

VickNV · February 19, 2020, 6:50pm

Some files under usr/include/aarch64-linux-gnu/ were installed from nvidia packages. Except those, it looks your other files under /usr/include/aarch64-linux-gnu/ may be from Ubuntu 16.04 packages (not installed with DRIVE Software) instead of Ubuntu 18.04.

For Ubuntu 18.04, this kind of header files should be under /usr/aarch64-linux-gnu/include/. So if your system has no thoese files from Ubuntu 16.04, you shouldn’t hit the issue. I guess that’s why no others reported the same issue.

klaus.kofler · February 20, 2020, 4:36pm

I can confirm that that my “/usr/include/aarch64-linux-gnu” folder looks like the one on a Ubuntu 16.04 machine, which has Drive 9 installed. But I don’t see why or how some Ubuntu 16.04 packages would be installed on my PC. It is not upgraded from Ubuntu 16.04 but a fresh install.

However, I still don’t know what compiler NVIDIA suggests to use for cross compilation. The 7.3.1 in the DriveOS directory or the 7.4.0 in the system directories.

Furthermore, when trying to run any of the samples on the target, they crash with a CUDA Error 218. Does anybody have an idea what may cause that?

VickNV · February 20, 2020, 5:15pm

I would say the one in Drive OS directory (part of DRIVE Software installation).

If it’s a different issue and no related topic existing, could you help create another topic for this?

klaus.kofler · February 20, 2020, 6:00pm

Ok, thanks for your help.