When I compile the basic matrxMul.cu program in the CUDA examples 3.0; I get the following error.
shrUtils.h: No such file or directory
I know the earlier versions of this program compiled with no problem, but this is the latest version and I am unfamiliar with the file shrUtils.h. I cannot search for it because i am using a computer remotely which is now locked. Where is this file? I am assuming that it was installed with the 3.0 version software, but the compiler is not finding it because there is no path to it. If I knew where it was, I would add a path to PATH.
You really will get a lot more done in a lot less time if you make the effort to read and understand the Linux and CUDA toolchain documentation. This “development and debugging by forum questions” methodology can’t be all that efficient.
That was the command that I was using. It is the same as yours and I got this error. I will use your command exactly as you state it and see what happens.
This command worked perfectly in a previous installation of CUDA.
Here it is not finding shrUtils,h. Since I know the file is on the disk and where it is, I must assume the compiler is not finding it because it is not in the path. I know now that $PATH has nothing to do with it, so I changed it back. I know that it must be LD_LIBRAY_PATH since that it only path remaining; when I installed an earlier version CUDA it instructed me to alter the LD_LIBRARY_PATH. I did not do this current installation and it is possible that the person who did the installing did not alter the LD_LIBRARY_PATH.
I am guessing that I must include
/home/errol/NVIDIA_GPU_Computing_SDk/shared/inc (the location of shrUtils.h)
Again, LD_LIBRARY_PATH also has nothing to do with this - it controls the ability of the linux runtime to find libraries when programs are run.
On my fresh version 3.0 SDK installation this works :
avidday@cuda:~/NVIDIA_GPU_Computing_SDK_3.0/C/src/BlackScholes$ nvcc -g -G -I../../common/inc -I../../../shared/inc -L../../lib -L../../../shared/lib -o BlackScholes BlackScholes.cu BlackScholes_gold.cpp -lcutil_x86_64 -lshrutil_x86_64
avidday@cuda:~/NVIDIA_GPU_Computing_SDK_3.0/C/src/BlackScholes$ ./BlackScholes
[BlackScholes]
./BlackScholes Starting...
Initializing data...
...allocating CPU memory for options.
...allocating GPU memory for options.
...generating input data in CPU mem.
...copying input data to GPU mem.
Data init done.
Executing Black-Scholes GPU kernel (512 iterations)...
Options count : 8000000
BlackScholesGPU() time : 5.915592 msec
Effective memory bandwidth: 13.523584 GB/s
Gigaoptions per second : 1.352358
BlackScholes, Throughput = 1.3524 GOptions/s, Time = 0.00592 s, Size = 8000000 options, NumDevsUsed = 1, Workgroup = 128
Reading back GPU results...
Checking the results...
...running CPU calculations.
Comparing the results...
L1 norm: 1.804101e-07
Max absolute error: 1.239777e-05
Shutting down...
...releasing GPU memory.
...releasing CPU memory.
Shutdown done.
[BlackScholes] - Test Summary
PASSED
Press <Enter> to Quit...
-----------------------------------------------------------
If you are using a 32 bit machine or have things in the a different place, the paths required for -I and -L will change, and so will the library names. I will leave it as an exercise to the reader to work out how they should be changed.
Below is my attempt to get matrixMul to compile (the program is unimportant, compiling an example is), but it says that it cannot find -lcutil_i386.a. On close examination of the output and specifically the include lists shows I gave it the path to -libcutil_i386.a. It still says that it cannot find it!
I believe that this is the 32 bit equivalent of the 64 bit command that you gave, however, it still is not finding -lcutil_i386.a. I give the path to -lcutil_i386.a (home/errol/NVIDIA_GPU_Computing_SDK/C/lib) and it says it cannot find the file.
I gave the path to -libshrutil_i386.a (/home/errol/NVIDIA_GPU_Computing_SDK/shared/lib) and it found the file.
I gave it the path to shrUtils.h (/home/errol/NVIDIA_GPU_Computing_SDK/shared/inc) and it found the file.
It finds everything, but -lcutil_i386.a. What is the error here?
The name. When you specify a library, don’t add any extension - the linker will look for shared or static versions automatically, so the link command should be just -lcutil_i386 . You can clearly see that in the example I posted.
Where is this discussed in the CUDA literature? I check the makefile for MatrixMul.cu an it does not even mention -libcutil.a or libcutil_i386.a.
I saw it in the posted example, true. It fact it easily compiled in earlier versions of CUDA - once I got the syntax right. But this one is seems different. It is much harder.
This time I put a copy of libcutil_i386.a in the same directory as the matrixMul code. It still gave the same error. I am assuming that there must be something wrong with the file. When it cannot find the file when it is even in the same directory as the source - the file has to be corrupted.
I am unsure as to how to test -libcutil_i386 accessibilitty any other way. Clearly, no matter what I do it still cannot access this file.
How can I test this file for correctness or corruptedness?
When providing a link command with “-l” , it will search for a file named “lib.so” or “lib.a”
So “-lcutil_i386” corresponds to the files “libcutil_i386.so” or “libcutil_i386.a”
You did not try my suggestion at all. Quoting myself (with emphasis):
To link libcutil_i386.a your link commands must be -lcutil_i386 and if the library is in a non-system path, that path must be supplied in a -L argument.
It isn’t. The library which you are trying to link with is an internal component of the SDK and not part of CUDA. It has no documentation and is not meant to be used for anything else. The actual arguments to nvcc to specify paths and libraries are briefly covered in the nvcc documentation (and the help nvcc will print using nvcc --help), but the description is brief because nvcc just follows the conventions used by gcc, and anyone with even passing familiarity with gcc (or just about any other unix compiler for that matter), will know what to do.
Nonsense. If you read the documentation for gcc or ld you will see that the current directory is not in the library search path by default. I am sure the library is fine - a corrupted file won’t generate a file not found error. You really need to spend some time and familiarize yourself with the gnu tool chain - make, gcc, ld . It will demystify all of this and make your life so much easier.
Please gives me a web address that discuses this. Linux books are at a premium around here, while websites are not. Anyway, the Linux book that I would get will probably discuss this topic lightly. It it just a good idea to get a website not a book. Please give me a website.