Cross Compilation using WSL2 for Jetson Nano

Hi,

I am trying to cross compile a simple helloWorld.cu file on WSL2 (Ubuntu 18.04). I intend to run the executable on Nvidia Jetson Nano 2GB board. Please provide some insight.

Hi,

You will need to have a cross compile toolchain for ARM and add the GPU architecture=sm_53 for Nano.

Below is a sharing from our user for your reference:

Thanks.

1 Like

Hi,
Can you share complete process to cross compile toolchain for ARM. I referred the pdf in the link shared but ran into trouble while cross compiling on WSL with Distro Ubuntu18.04

Hi,

Below is a tutorial but he use docker and armv7.
For Nano, you will need to compile it for aarch64

If the tutorial is not working on your environment, please check with WSL team to see if they can support cross-compile an ARM binary first.

Thanks.

Hi AastaLLL,
Thanks for sharing the link. I was able to get that to working in my environment. However, I still ran into issues while trying to cross compile on X86 for Jetson. I could not compile the mxnet part. If you can share some thoughts, it would be really helpful

Also, after setting the environment variables as described in the ppt document, when I try to compile helloworld.cu file, I get below error:
$NVCC Chkhello.cu -m64 --gpu-architecture=sm_53 -target-dir aarch64-linux -o Nanohello
/lib/ld-linux-aarch64.so.1: No such file or directory

Hi,

If you are using MXNet, you need to copy the library (for aarch64) back to X86 for compiling.

More, some extra configure is required for the cross-compile with nvcc directly:
https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#cross-compilation

Thanks.

This is all quite confusing. I repeated the whole process and still couldnt get the cross compiler work on Jetson nano.

Is it possible that I compile a cuda program in windows or WSL2 and run the generated out file on a Jetson Nano 2GB board

Keep in mind that if your program requires linking to a library, then the library to be linked must be present, and it must exist somewhere in the linker’s search path. It isn’t enough to simply add the file. Also, if that library links to other libraries, then those too must be present. I don’t think WSL2 has the ability to use loopback, but typically, when figuring out libraries, what I do is loopback mount the entire Jetson image. I’m not sure on WSL2 how to research what the linker path is, but you will probably want to start with that.

So what solution do you suggest? I want to compile my cuda code on Windows machine (either using Visual Studio or WSL) and run the executable onto Jetson Nano 2GB board

I have not worked with setting up WSL, so I can’t say for certain. However, some trivia about linking on actual Linux is probably useful with WSL as well:

  • To see all libraries the linker currently sees: ldconfig -p.
    Does your WSL have the ldconfig command available? Notice that each line of output mentions the library name, then the full path.
  • The actual linker is “ld”. A more “brief” listing can be found via:
    ld --verbose | grep SEARCH_DIR
  • On actual Linux there tends to be a configuration file for the linker at:
    /etc/ld.so.conf
    …and customization files in:
    /etc/ld.so.conf.d/
    (these files typically are added for individual application requirements, e.g., a desktop PC would put a CUDA file there naming the library location “/usr/local/cuda-10.2/targets/x86_64-linux/lib” or similar)
  • Most likely if you have your libraries located in a location already in the linker search path, then there isn’t anything required.
  • Most likely if you have libraries in a subdirectory of “/usr/local/...something.../”, then you’ll need to add a search path to a new file in “/etc/ld.so.conf.d/”, and then it would work.
  • If you incorrectly modify the linker search path, then it is possible the system will fail to boot until corrected. Normally, if you add a new path without modifying the default linker path this won’t be a problem, e.g., it isn’t much of a risk to add “/usr/local/mylibs/” via “/etc/ld.so.conf.d/”, but modifying an existing library in a default system path could have some risk to it.
  • If you manually update something in the linker path and wish to have the linker see the update without rebooting, then you would run the command “sudo ldconfig” (without the “-p” option). If something has gone wrong, then you can probably still fix the problem without effort so long as you don’t reboot.
  • The file name in “/etc/ld.so.conf.d/” is simply something with meaning in case, e.g., named after the application or purpose of the linker search path edit, and ending in the “.conf” suffix.

I cannot tell you all of the requirements for setting up the linker for your compilation requirements since one library can require another library, and there can be an entire tree of requirements simply by adding one library. It is, however, fairly easy to try to link, and add whatever library the linker error says is missing. So long as some kernel features (such as loopback) are not requested in WSL I think this stands a reasonable chance of working without needing more than addition of some libraries, followed by adding whatever custom location the linker needs to know about.

1 Like