I will keep working until I find a workaround!
Thank you for your response; it was very helpful, and now I understand the issue better than before.
By the way, I love the Jetson Nano; well done designing it.
Thank you for having DEV kits available at a reasonable price well appreciated. It just means I can have several of them on my desk, running multiple versions of code, and the people who supply YouTube videos.
Solved OPENCV with CUDA support - DONE
Jetpack 36.4.4-gcid-41062509 - Done
Question? Where can you find the libs ? or C++ for Visual Studio Code
g++: error: unrecognized command-line option ‘-m64’
g++: error: unrecognized command-line option ‘-mssse3’
Works with an OLDER Version of g++
Migrating C++ Code from Hungry Power machine Ubuntu 18.04
Thus… SAME speed just with CPU’s.
g++: error: unrecognized command-line option ‘-m64’
g++: error: unrecognized command-line option ‘-mssse3’
I have NOT used OPENCV with CUDA ! YET !
Strongly Recommended after Jetson SDK Manger adds missing libraries & dependencies. UBUNTU has Archived a few, useful for old budies UBUNTU 18.0
Any ideas to Compile
Of course. It appears you’re looking for information on how to compile this project with an older version of g++ on a 64-bit system. This is a common situation when using older NVIDIA CUDA toolkits, which often have strict requirements for the host compiler version.
SSSE3 is a set of CPU instructions that perform SIMD (Single Instruction, Multiple Data) operations. This allows the CPU to perform a single operation on multiple pieces of data simultaneously, which can lead to significant performance improvements for tasks involving heavy computation, such as the large-number arithmetic required for elliptic curve cryptography in this project.
I can’t answer most of that. Something useful to do though is to cd to “/usr/local”. Then run “ls -F”. Do you see anything for CUDA? I typically find a bin/ and maybe a lib/ within that, and then create symbolic links to some locations searched by default. I might even add something to default locations.
An example, what do you see from “echo $PATH”? Is “/usr/local/bin” in that path? If it is, and if you see a CUDA location for the release version you are interested in (I’ll pretend it is “/usr/local/cuda-12”, with accompanied “/usr/local/cuda-12/bin”), I might do this:
cd /usr/local/bin
sudo ln -s ../cuda-12/bin/* .
This puts those bin files within the local bin without actually copying files over (updates would work as expected). If /usr/local/bin itself is not in your $PATH, then you could open your ~/.bashrc and change to this:
# assuming original PATH is "/usr/sbin:/usr/bin:/sbin:/bin", then adding
# "/usr/local/bin" at a higher priority is:
export PATH=/usr/local/bin:$PATH
Always test to see if it works before you log out or stop editing:
source .bashrc
echo $PATH
# Assuming you now see file "/usr/local/bin/nvcc", this should find it too:
which nvcc
For libraries there is something similar, but you don’t want your library path to be incorrect. It can hang boot if do something like name a non-existent location. This is a contrived example, but on a desktop PC I see this within my “/usr/local/cuda/” content (useful as an example):
/usr/sbin:/usr/bin:/sbin:/bin
I can print my current library search path with “ldconfig -p”. If I do this, and if that file is not in the path, I get no output:
ldconfig -p | egrep -i libnppig.so
If it is in my path, then it echoes the location.
I could directly add an entire location to the path, e.g., I could add “/usr/local/cuda/targets/” to search (it’d find recursive content in theory), or I could do something similar to the original $PATH (I prefer this). If you verify nothing shows up in “ldconfig -p | egrep -i local”, then we could go to “/usr/local/lib/”, and then (contrived locations; some of this is amd64 and not from a Jetson):
ln -s ../cuda/targets .
ls
At this point the libraries are visible in “/usr/local/lib”, but not yet in the search path. If you use sudo -s you can drop into a root shell, then cd /etc/ld.so.conf.d/". Run ls. Note that all of the .conf files are just individual locations to be searched for library files. Those locations must exist, or it could hang boot.
To see if any have local in them:
egrep local *.conf
To see if any have cuda in them:
egrep -i cuda *.conf
They are plain text, and you could just use “cat <filename>” to see examples.
You could create a new file, e.g., one named after a given CUDA release, and containing the path to the “/usr/local/cuda-12/targets”, naming it something like 000_cuda-12.conf. Or you could name “/usr/local/” and call it “000_local.conf”. If 000_local.conf the file content would be:
/usr/local/lib
Then we could refresh the search path (the “ld path”) via:
ldconfig
(it is option “-p” which makes it print instead of refresh)
After this we should see a grep of the new path containing whatever was added, e.g.:
ldconfig -p | egrep -i (local|cuda)
(a case-insensitive search for either the token “local” or “cuda”)
If it turns out that a file is not being found, and that file is in a subdirectory and not the named directory, then you could simply refine the search path from something like “/usr/local/lib/targets/” to name the path to the containing directory (don’t name the file itself, name only the directory holding it).
Always run “ldconfig” to update the library search path, and then ldconfig -p to see if it works without error before you exit your sudo -s root shell. You want to be able to reverse any change if something has gone wrong prior to exiting.
Do note that a number of applications will directly look for certain libraries. The above is for the general “default search path” and won’t help if an application is looking for a full path to a specific library and is not using default search path.
Also, may options depend on major release version of libraries, compilers, or compile settings. This is very much dependent upon the actual software being compiled. We can talk about those, but the other needs to run first, and then a log of a build in a log file attached to the forum (showing all of the compile might be needed, but if it isn’t in an attached text file, then it’ll overwhelm the forum).