CUDA programming guide states that:
the driver API is backward compatible, meaning that applications, plug-ins, and libraries (including the C runtime) compiled against a particular version of the driver API will continue to work on subsequent device driver releases
I understand this as that, if my code was compiled on CUDA4, the binary will run on CUDA5. However, it turned out that running the CUDA5-compiled binary on CUDA5 led to:
error while loading shared libraries: libcudart.so.4: cannot open shared object file: No such file or directory
Note that I am using the "module" facility in Linux to switch in between different cuda versions, i.e.
module load cuda4
compile
module unload cuda4
module load cuda5
run
It is the developers responsibility to package libcudart.so.4 with the application. The module command is likely changing your LD_LIBRARY_PATH or your PATH variable so LDD is not finding libcudart.so.4. I recommend you add a post build step to copy the required .so into your application directory.
ATTACHMENT A in EULA.txt at the root of the CUDA Toolkit directory lists the Redistributable Software. This includes libcudart.so (and variations that have version number information embedded in the file name). This also includes libcufft, libcublas, ...
Related
I'm compiling the source code by using pgf95 (Fortran compiler).
If I use cuda 10.0, it successfully compiles the source code.
However, If I use cuda 10.1, it fails showing that 'cannot find libcublasLt.so'.
When I scan the directory cuda-10.0/lib64, cuda-10.1/lib64, both do not have the file starting with 'libcublasLt'.
How can I solve this issue?
libcublasLt.so is the library that provides the implementation for the cublasLt API which is defined here. It just happens to be a separate shared object from libcublas.so
In the past (e.g. CUDA 10.0 and prior), most CUDA libraries were installed in /usr/local/cuda/lib64 (or similar) by default (on linux). At about the CUDA 10.1 timeframe, it was decided that some libraries would be installed in different places. CUDA 10.1 is also where the cublasLt API and library were introduced. This affected some cublas libraries and is discussed in the CUDA 10.1 release notes here (both the introduction of the cublasLt library, as well as the change in library locations).
So there are 2 possibilities here (for CUDA 10.1, CUDA 10.2):
libcublasLt.so is on your machine, but it is simply not where you were expecting to find it.
libcublasLt.so is not on your machine. This means you are working with CUDA version prior to the introduction of the cublasLt API (i.e. 10.0 or prior), or you have a broken install.
So, assuming you are working with CUDA 10.1 or CUDA 10.2, the first step is to locate/determine whether libcublasLt.so is on your machine or not. You can use a linux utility like find or locate to accomplish that. They should have man pages available for you.
If you can find it, then you need to provide the path to it, via a linker spec (e.g. -L/path/to/libcublasLt.so/
If you can't find it, then either you are working with an older version of CUDA (10.0 or prior), or you need to reinstall CUDA.
I believe by the time you get to CUDA 11.0, the CUDA packages put the cublas libraries back in /usr/local/cuda/lib64 with the other libraries. YMMV.
I compiled MySQL++ with no issues. When I launched some of the executables (resetdb.exe and simple1.exe) they suggest to run to test if the installation has been successful, the first error I got was that libmysql.dll was missing.
Adding its path to the PATH environment variable did not fix the problem, even after launching a new command prompt; I had to copy the DLL in the directory where MySQL++ executables are.
Now the DLL is found, but I get this error:
simple1.exe - Application error
The application was unable to start correctly (0xc000007b).
Click OK to close the application.
even launching from the command line, I get no more information than these.
Thank you for any help!
MySQL 5.5 -
MySQL++ 3.0.9 -
Windows 7 64 bits -
MINGW32 -
GCC 4.4.0
0xC000007B is a Windows error that means the executable is corrupted. It could refer either to simple1.exe or to one of the DLLs it's linking against.
Some reasons this could happen:
You're mixing toolchains in an incompatible way. In your case, you may have built simple1.exe using pieces built by MinGW GCC and pieces built by Visual C++. MinGW should be compatible with any pure C DLL built by Visual C++, including the MySQL C API DLL. However, you may have other pieces interfering. MinGW isn't compatible with VC++ at the C++ level, but then, it shouldn't have linked at all if this were your problem.
You didn't follow the MySQL C API import library build steps in README-MinGW.txt. You either missed a step, or skipped it entirely and are trying to use the import library that shipped with MySQL.
In your previous gyrations, you ended up with a corrupt object file, which got linked in. Try saying make clean all at the top level of MySQL++ to force a complete rebuild.
You're mixing versions of MySQL or MySQL++. If you have more than one version of each on the system, make sure you're consistent in their use. That is, build the C API import library from the same DLL you run the programs against, use exrun.bat to run the examples to ensure you're using the just-built version of the MySQL++ DLL instead of another you have in your PATH, etc.
Additionally, I note that you're using an older version of MySQL++. If you were on Linux, I could understand that as some distributions still ship with 3.0.9. But since you have to build MySQL++ from source with MinGW, I don't see why you're not using 3.1.0. Did you get a binary build from somewhere?
As for your PATH problem, did you restart the MinGW shell after doing this? PATH updates don't affect running programs; they keep the value they saw when they started.
I am using CUDA 4.0 . I am trying to use the following functions.
CUT_DEVICE_INIT();
CUT_SAFE_CALL(cutCreateTimer(&hTimer));
I included cutil.h to use the above functions. But the compiler reports the following..
fatal error C1083: Cannot open include file: 'cutil.h': No such file or directory
I searched in the CUDA directory but there is no file 'cutil.h'.
How can I find the time needed for a CUDA function using the above method? (not using the C++ timer)
You probably didn't tell your compiler where to find the file. I can't tell you exactly because you didn't provide details on what system you are using but for example, on Windows XP and assuming a default installation of version 4.0 of the SDK the cutil.h header file is in:
C:\Documents and Settings\All Users\Application Data\NVIDIA Corporation\NVIDIA GPU Computing SDK 4.0\C\common\inc
For Windows 7 I think it is:
C:\Program Data\NVIDIA Corporation\NVIDIA GPU Computing SDK 4.0\C\common\inc
but not sure.
I want to interact with a MySQL database from Matlab.
I found a mysql "library" for matlab here and the same on mathworks.
I followed the instructions to compile the library and the compilation seems to be successful. I get a mex32 file at the end. Only, the instructions on the first page refer to a Dll that I need to use (I guess that a Dll was supposed to be generated).
I am not familiar with the mex compiler or with compiling external modules for Matlab.
Am I missing something trivial? Where is the Dll supposed to be?
Thanks.
The reference to the dll is obsolete.
When you compile a mex function on Windows, you compile it as a dll (not an .exe). Thus, compiled mex functions used to have the extension .dll. Mex-functions with .dll extensions still work, but there is a warning that this might stop being the case in the future.
When 64-bit Windows arrived, TheMathWorks needed a way that people were to be able to compile the same mex-function for both Win32 and Win64, thus they changed the extension to .mexw32 and .mexw64, respectively. Apparently, they did not update the documentation completely.
I'd recommend using java to connect MATLAB and MySQL (or any other db if required).
The java database connector is simple to set up. I built a simple java class to connect to the database - see previous posting for a crude but working solution.
The MATLAB code works as indicated
% include java class
import Jam.ConnectToDatabase
% set up database connection info
userName='myName';
userPassword='myPassword';
databaseUrl='jdbc:mysql://glnd2818898.internal.net/2000';
% create java class instance and open connection to the database
ctd = ConnectToDatabase;
ctd.openConnection(userName, userPassword, databaseUrl)
Once the connection is open I can then use the java methods to submit SQL queries, create tables, insert data etc. I'd never used java before but I downloaded Netbeans and I was away.
OK, here is the solution to my problem.
The compilation does generate a mex32 file (32 is because I compiled it under a 32bit systme). You can check the output file of the compilation by running mexext. So apparently a mex32 file is a compiled version of the C file.
Once I placed the file in a directory that is in the Matlab's path it worked.
I guess the reference to the Dll in the link I provided is either obsolete or wrong.
I'm getting this error while trying to run sample codes in CUDA SDK. I have CUDA 2.3 and Visual studio 2008
LINK : fatal error LNK1181: cannot open input file 'cutil32D.lib'
Any pointers how to solve this?
Since you're compiling the SDK samples, the project files are probably correct. Far more likely is that you haven't built the cutil library. Go to the SDK install directory, then into the "C" directory. You'll see a "common" directory, in there open the cutil.sln solution (or cutil_vc90.sln for VS2008) and build it in release and debug modes for your platform.
Then try your sample again.
The cutil library is used to avoid replicating the same code through all the samples, if you're starting your own project I'd avoid reusing the cutil library and write your own checker. For example, you should probably fail gracefully if you detect a CUDA error rather than just calling exit() as done in cutil.
The cuda.rules file included in the SDK is highly recommended! Using this you can just add .cu files to any project and Visual Studio will know how to compile them and link them in to the final executable. Easy!
Your MSVC project needs to include the library cutil32D.lib to link. Once you specify it as a library the linker needs to include in the final binary artifact this problem will go away. It would seem the library is missing at the location the linker is going to look for it. You'll have to change the library search paths or move that file to a directory in which the linker is already looking.
I ran into the same issue. It turned out not only did I need to build the cutil project but also the shrUtils project under the SDK's shared folder.