Cannot find -lcutil64

Hi, all

I have developed a CUDA application on windows XP with CUDA 3.0. Now I am trying to migrate my code to a Tesla machine that has an Ubuntu 9.04 operating system. I have installed the Developer Drivers for Linux (195.36.15), cmake 2.8.0 (the same as in windows) and nVidia CUDA sdk from CUDA 3.0 download website (http://developer.nvidia.com/object/cuda_3_0_downloads.html#Linux).
After using ccmake I get my Makefile and try to “make” it. However I get the following error:

Linking CXX executable test
/usr/bin/ld: cannot find -lcutil64
collect2: ld returned 1 exit status
make[2]: *** [InstanceGenerationGpu/test] Error 1
make[1]: *** [InstanceGenerationGpu/CMakeFiles/test.dir/all] Error 2
make: *** [all] Error 2

I have looked through my nVidia_CUDA_SDK/C/lib and also nVidia_CUDA_sdk/lib directories and they do not contain cutil64 library, which maybe the reason for this error.

Has anyone had this problem before? Any help would be appreciated.

DarkTerror

Had the same problem on Ubuntu 9.04 64-bit server edition. I think cutil64 is a library that the SDK tries to build only for the examples, but whose build fails if you don’t have the right development packages installed. Have you installed xorg-dev yet (sudo apt-get install xorg-dev)? You’ll need it. After installing xorg-dev, that problem went away.

If that doesn’t work, I have a list of things I did to get CUDA working on my machine that I could send you.

Well this is embarrassing. I just realized that the administrator has forgotten to “make” nVidia_CUDA_SDK :"> . Since I do not have administrative privileges, I cannot “make” it either and I have to wait until the weekend ends. I will see if the problem resolves after “making” the libraries.

By the way thanks for brainstorming with me.

DarkTerror

No, the problem still persists. I have the following library in my lib folder: libcutil_x86_64.a. Is this what it is looking for?

Can you also tell me the other things that you did to get it working?

Thanks

DarkTerror

You can make it in your own directory as a user… then just update your include and LD_LIBRARY_PATH variables to point to your local copy.

I think the file would be libcutil64.so .

There’s a second point… it’s usually a Bad Idea to be using cutil in your own code. Cutil is an unsupported, unadvertised, little library used by the SDK examples, and you can learn from it. But it’s not standardized, documented, supported, officially maintained, or anything. If you’re using cutil, it’s likely just for some of the macro wrappers or perhaps the little timer class… so just pull out those parts and put it straight into your code.

I have pointed this out often, and I will do it again here - LD_LIBRARY_PATH is a runtime shared library link loader setting. It will have no effect in this case, or any case where user supplied libraries need to be searched for during the linking phase of compilation. The only role it ever plays during complialtion is in resolving of dynamic shared library dependencies. If you don’t believe me, consider the following trivial example:

avidday@cuda:~$ echo "int main(void) { return 0; }" > junk.c

avidday@cuda:~$ echo $LD_LIBRARY_PATH 

/opt/cuda-3.0/lib64:/opt/cuda-3.0/cudaprof/bin

avidday@cuda:~$ ls /opt/cuda-3.0/lib64

libcublasemu.so		 libcublas.so		 libcudartemu.so		 libcudart.so		 libcufftemu.so		 libcufft.so

libcublasemu.so.3	   libcublas.so.3	   libcudartemu.so.3	   libcudart.so.3	   libcufftemu.so.3	   libcufft.so.3

libcublasemu.so.3.0.14  libcublas.so.3.0.14  libcudartemu.so.3.0.14  libcudart.so.3.0.14  libcufftemu.so.3.0.14  libcufft.so.3.0.14

avidday@cuda:~$ gcc junk.c -lcudart

/usr/bin/ld: cannot find -lcudart

collect2: ld returned 1 exit status

avidday@cuda:~$ gcc junk.c -L/opt/cuda-3.0/lib64 -lcudart

avidday@cuda:~$ ldd a.out

	linux-vdso.so.1 =>  (0x00007fff83ccc000)

	libcudart.so.3 => /opt/cuda-3.0/lib64/libcudart.so.3 (0x00007fc2455ca000)

	libc.so.6 => /lib/libc.so.6 (0x00007fc245258000)

	libdl.so.2 => /lib/libdl.so.2 (0x00007fc245054000)

	libpthread.so.0 => /lib/libpthread.so.0 (0x00007fc244e38000)

	librt.so.1 => /lib/librt.so.1 (0x00007fc244c30000)

	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fc244923000)

	libm.so.6 => /lib/libm.so.6 (0x00007fc24469e000)

	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fc244486000)

	/lib64/ld-linux-x86-64.so.2 (0x00007fc245805000)

So please stop telling people it will.