For the third party libararies, are they available in Linux? One tool you have is the package system’s search tool. Examples:
apt search botan
apt search srt
Answers are not guaranteed to be what you are actually looking for, but if they are, then this might be what you are interested in:
sudo apt-get install botan
sudo apt-get install srt-tools
It might be useful to list all packages currently on a system, but filter for the ones with the “-dev” in their name (grep and egrep are topics all on their own, but the short story is that they are regular expression filters; the filtering you are normally used to is called globbing):
dpkg -l | egrep '\-dev'
If you see a specific package and want to know which repository it came from (which is a source listed in “/etc/apt”, mentioned later), here is an example using the “bash” package:
apt policy bash
The part which is less obvious is that to compile the software against those libraries you need the “dev” packages (which contain the header files to #include). In the case of more or less standard software (ones which are available on the default servers) this isn’t usually a problem if you understand the name of the package (sounds a bit like a cliched horror moving), but some third party packages require adding their apt repository. In yet other cases a third party might make available headers for building against the library as a simple tarball package (anything archived with the “tar” tool is referred to as a tarball; the file name usually has .tar in it, but if combined with gzip or bzip2 compression, then it might look like “something.tar.gz”, “something.tar.bz2”, “something.tgz” or “something.tbz2”, or similar; .tgz is the same as .tar.gz, and similar for .tar.bz2 being the same as .tbz2).
To complicate it a bit more, there are often different official repositories based on standard use or for third parties, or maybe for licensing differences. You might want to explore the file “/etc/apt/sources.list” to see the default repository setup. This is basically a bash script, and lines starting with “#” are comments. The supplemental repositories which were added are usually in “/etc/apt/sources.list.d/” and have the same format, but keep the official sources.list clean. Other directories are for things like PGP keys.
About C++20: You might end up regressing to C++17. It depends on what is available by default on the Jetson. Note that gcc (and g++) have several standards available, and you usually have to pick via an argument to the g++ compile line if it is angccorg++`ything other than the default. Man pages typically are not installed by default on a Jetson, but you can expand those and add them (I’d have to look up the command) to see on a Jetson. Your host PC would have the man pages already. Some useful information you might copy for later use is the output from:
The g++ version changes with the Ubuntu release, and currently the Ubuntu 20 release is used. Around Dec. 5 of this year a new JetPack release will come out which supports an L4T release which is Ubuntu 22, and is compatible with Orin. This will probably have a new g++ release which will support more C++ extensions. However, for the moment, if we were to look at the information for specifying g++ use C++17, then start with:
man g++
Then search (it is a regular expression, not globbing) for “c++17” via this (which has some escaping in it…regular expressions are very very definitely worth your time to understand the basics of):
/c\+\+17
(the slash / key in the man pages drops into regular expression search, the “c\+\+17” search for an exact match to “c++17”…but sometimes you want case-sensitive, in which you would have to toggle to case-sensitive with the “-i” key sequence within the man page)
So far as video goes I’m the wrong guy to ask. However, your biggest issue in porting from PC to Jetson (if both use Linux) is detecting the GPU for GPU-accelerated apps. Many applications do this with the nvidia-smi application, but this is for PCI based discrete GPUs (dGPU), and does not exist for integrated GPUs (iGPU). I would expect you will be asking questions specific to video which includes detecting GPUs if you are going to use specific abilities (OpenGL/OpenGLES is not a specific ability such as CUDA version; if you use the right OpenGL release, then it should just work; other more specific features require a query of the GPU). Consider asking a separate forum thread for any given API you are interested in, especially if it is related to GPU or video. An example of a good thread on the forum is tgccorg++`o ask about requirements for using AAC encoding, and giving a short clip of the C++ code which worked in a different environment, but which you want to port.
Networking on Linux tends to be much easier to deal with than on Windows. On the other hand, some services you might need will require installing some network toolkit and kernel driver which is compliant with the Windows version. This means that although basic networking is easier, that when you go to work with services originally created for other operating systems, that this might be a more difficult question and probably also deserves its own forum thread. I can’t answer most of your services questions because they are designed for Windows (you won’t get a WIN32 API, although there might be a VM or Docker substitute).
CMake is widely available and works quite well on Linux. You won’t have an issue with that, but what CMake uses in terms of packaging of various software might be a problem (see the earlier mention of the apt package system; those are Linux packages, but sometimes they exist for both Linux and Windows without effort, while at other times there is some name translation, and yet other cases will be you porting it). CMake itself won’t be an issue.
Jetsons are entire operating systems and useful for anything a desktop Linux system is useful for. The main difference is that it uses less RAM for older Jetsons (there is plenty on an Orin NX), and always disk space is at a premium. If you have the disk space, any Orin is actually a pretty good compile device. You might want to set the power model to the max (usually “sudo nvpmodel -m 0”, but see the docs for the L4T release), and then peg the clock to max within that model (“sudo jetson_clocks” maxes within the current nvpmodel; these go away at reboot unless you’ve taken steps).
The previous paragraph reminds me of something about make that you will find useful (CMake will be similar) called the “job server”. If you are in a power model which has 12 cores, then the “-j 12” option to a Makefile gcc or g++ compile line would use 12 cores to aid building. This only helps in cases where it is marked as “independent”. I’m not very good at explaining this, but you could need to compile a lot of .o object files from .cxx source files, and each .o is its own compile. Then there is a linker stage which uses all of the .o files at the same time. If you have 12 CPU cores, then you might want to build 12 .o object files at the same time on different cores. That’s the job server. I have not set it up with CMake, but I’m sure there is an equivalent to the Makefile “-j #” job server option. As long as you have enough RAM this really speeds things up (each “job” uses its own RAM…lots of jobs mean lots of RAM…but Orins tend to tackle this quite well and it can greatly speed up builds). When compile is taking too long consider lookup up the job server.