I have the cuda 4.0 toolkit installed in my Ubuntu 12.04 server. When I am trying to build a cuda code present in Rodinia benchmark suite. I was getting the following error. i.e, after running the make command
ncclab#slave13:~/Downloads/rodinia_2.4$ make
cd cuda/cfd; make; cp euler3d euler3d_double pre_euler3d pre_euler3d_double /home/ncclab/Downloads/rodinia_2.4/bin/linux/cuda
make[1]: Entering directory `/home/ncclab/Downloads/rodinia_2.4/cuda/cfd'
nvcc -O2 -Xptxas -v --gpu-architecture=compute_20 --gpu-code=compute_20 euler3d.cu -o euler3d -I/if10/kw5na/NVIDIA_GPU_Computing_SDK4/C/common/inc -L/if10/kw5na/NVIDIA_GPU_Computing_SDK4/C/lib
euler3d.cu:35: warning: #warning "the kernels may fail too launch on some systems if the block length is too large"
euler3d.cu:35: warning: #warning "the kernels may fail too launch on some systems if the block length is too large"
By here the euler3d was built
nvcc -Xptxas -v -O3 --gpu-architecture=compute_20 --gpu-code=compute_20 euler3d_double.cu -o euler3d_double -I/if10/kw5na/NVIDIA_GPU_Computing_SDK4/C/common/inc -L/if10/kw5na/NVIDIA_GPU_Computing_SDK4/C/lib
/tmp/tmpxft_0000532d_00000000-12_euler3d_double.o: In function `main':
tmpxft_0000532d_00000000-1_euler3d_double.cudafe1.cpp:(.text+0x22d9): undefined reference to `cutCreateTimer'
tmpxft_0000532d_00000000-1_euler3d_double.cudafe1.cpp:(.text+0x22f7): undefined reference to `cutStartTimer'
tmpxft_0000532d_00000000-1_euler3d_double.cudafe1.cpp:(.text+0x2457): undefined reference to `cutStopTimer'
tmpxft_0000532d_00000000-1_euler3d_double.cudafe1.cpp:(.text+0x246c): undefined reference to `cutGetAverageTimerValue'
collect2: ld returned 1 exit status
make[1]: *** [euler3d_double] Error 1
make[1]: Leaving directory `/home/ncclab/Downloads/rodinia_2.4/cuda/cfd'
cp: cannot stat `euler3d_double': No such file or directory
cp: cannot stat `pre_euler3d': No such file or directory
cp: cannot stat `pre_euler3d_double': No such file or directory
make: *** [CUDA] Error 1
By searching I came to know that there may be a problem with libcutil
But I had the libcutil_x86_64.a in ~/NVIDIA_GPU_Computing_SDK/C/lib
Edit: The contents of various folders are
ncclab#slave13:~/NVIDIA_GPU_Computing_SDK/C/lib$ ls
libcutil_x86_64.a libparamgl_x86_64.a librendercheckgl_x86_64.a
~/Downloads/rodinia_2.4/cuda/cfd$ ls
euler3d euler3d_double.cu Makefile~ pre_euler3d.cu README
euler3d.cu Makefile Makefile_nvidia pre_euler3d_double.cu run
ncclab#slave13:~/NVIDIA_GPU_Computing_SDK/C/common/inc$ ls
bank_checker.h cutil_inline.h GL nvVector.h stopwatch_base.h
cmd_arg_reader.h cutil_inline_runtime.h multithreading.h nvWidgets.h stopwatch_base.inl
cuda_drvapi_dynlink.c cutil_math.h nvGlutWidgets.h paramgl.h stopwatch.h
cutil_gl_error.h dynlink nvGLWidgets.h param.h stopwatch_linux.h
cutil_gl_inline.h dynlink_d3d10.h nvMath.h rendercheck_d3d10.h
cutil.h dynlink_d3d11.h nvMatrix.h rendercheck_d3d11.h
cutil_inline_bankchecker.h error_checker.h nvQuaternion.h rendercheck_d3d9.h
cutil_inline_drvapi.h exception.h nvShaderUtils.h rendercheck_gl.h
the partial contents of the makefile are
all: euler3d euler3d_double pre_euler3d pre_euler3d_double
euler3d: euler3d.cu
nvcc -O2 -Xptxas -v --gpu-architecture=compute_20 --gpu-code=compute_20 euler3d.cu -o euler3d -I$(CUDA_SDK_PATH)/common/inc -L$(CUDA_SDK_PATH)/lib $(CUTIL_LIB)
euler3d_double: euler3d_double.cu
nvcc -Xptxas -v -O3 --gpu-architecture=compute_20 --gpu-code=compute_20 euler3d_double.cu -o euler3d_double -I$(CUDA_SDK_PATH)/common/inc -L$(CUDA_SDK_PATH)/lib $(CUTIL_LIB)
pre_euler3d: pre_euler3d.cu
nvcc -Xptxas -v -O3 --gpu-architecture=compute_20 --gpu-code=compute_20 pre_euler3d.cu -o pre_euler3d -I$(CUDA_SDK_PATH)/common/inc -L$(CUDA_SDK_PATH)/lib $(CUTIL_LIB)
pre_euler3d_double: pre_euler3d_double.cu
nvcc -Xptxas -v -O3 --gpu-architecture=compute_20 --gpu-code=compute_20 pre_euler3d_double.cu -o pre_euler3d_double -I$(CUDA_SDK_PATH)/common/inc -L$(CUDA_SDK_PATH)/lib $(CUTIL_LIB)
The euler3d has been successfully built. The errors are occurring for all the remaining three files.So I don't think there is any problems in the directories they are referring to
I really don't understand why the undefined reference to `cutCreateTimer' and others are occurring. But searching in SE I came to know that when there is any problem with cutil.h or libcutil these problems exits. I was a newbie of linux environment. So please help me
Edit 2: In a include file named make.config the following lines were present
# CUDA SDK installation path
#SDK_DIR = $(HOME)/NVIDIA_GPU_Computing_SDK/C
SDK_DIR =/if10/kw5na/NVIDIA_GPU_Computing_SDK4/C
#SDK_DIR =/if10/kw5na/NVIDIA_CUDA_Computing_SDK4/C
Here by default the 2nd option was selected and the euler3d was built. So I thought there may be a problem because of this. But changing it does not change the problem I was facing
and about cutil library present in make file
CUDA_SDK_PATH := $(SDK_DIR)
# Determine the correct version of the cutil library
CUTIL_LIB = # -lcutil
ifeq ($(shell uname -m), x86_64)
ifeq ($(shell if test -e $(SDK_DIR)/lib/libcutil_x86_64.a; then echo T; else echo F; fi), T)
CUTIL_LIB = #-lcutil_x86_64
endif
endif
Which I think was correct
The problem is that your compile command is specifying the library path, but not the library itself that is providing the cut... functionality.
This is apparently the makefile line that is generating the nvcc compile command for euler3d_double:
euler3d_double: euler3d_double.cu
nvcc -Xptxas -v -O3 --gpu-architecture=compute_20 --gpu-code=compute_20 euler3d_double.cu -o euler3d_double -I$(CUDA_SDK_PATH)/common/inc -L$(CUDA_SDK_PATH)/lib $(CUTIL_LIB)
This is the generated compile command:
nvcc -Xptxas -v -O3 --gpu-architecture=compute_20 --gpu-code=compute_20 euler3d_double.cu -o euler3d_double -I/if10/kw5na/NVIDIA_GPU_Computing_SDK4/C/common/inc -L/if10/kw5na/NVIDIA_GPU_Computing_SDK4/C/lib
You'll note that the last two tokens in the makefile line are:
-L$(CUDA_SDK_PATH)/lib $(CUTIL_LIB)
The -L$... token is getting converted to the correct library path. But the $(CUTIL_LIB) token should be getting converted to something like -lcutil or perhaps -lcutil_x86_64, but that is not happening. As a result, the library that provides the cut...Timer... functions is missing, and so those appear to be undefined.
I would inspect the Makefile carefully to see if there are any end-of-line characters or other oddities that are different between the line that specifies how euler3d_double should be built and the previous lines that specify how euler3d should be built.
You should also be able to confirm this by looking at the nvcc compile command line generated for euler3d (which you don't show) and comparing it to the one for euler3d_double (which is failing).
Related
While verifying cuDNN install on Linux as the docs implied:
Compile the mnistCUDNN sample. $make clean && make
I encountered error as below:
XXX#XXX ~/cudnn_samples_v7-master/mnistCUDNN $ make clean && make
rm -rf *o
rm -rf mnistCUDNN
/usr/local/cuda/bin/nvcc -ccbin g++ -I/usr/local/cuda/include -IFreeImage/include -m64 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_53,code=sm_53 -gencode arch=compute_53,code=compute_53 -o fp16_dev.o -c fp16_dev.cu
g++ -I/usr/local/cuda/include -IFreeImage/include -o fp16_emu.o -c fp16_emu.cpp
In file included from fp16_emu.cpp:50:
fp16_emu.h:55:10: fatal error: driver_types.h: No such file or directory
#include <driver_types.h>
^~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:200: fp16_emu.o] Error 1
I tried:
sudo find / -name driver_types.h
And I found driver_types.h is actually in
/usr/local/cuda/targets/x86_64-linux/include/
rather than
/usr/local/cuda/include .
So I replace the
CUDNN_INCLUDE_PATH ?= $(CUDA_PATH)/include
with
CUDNN_INCLUDE_PATH ?= $(CUDA_PATH)/targets/x86_64-linux/include
in cudnn_samples_v7/mnistCUDNN/Makefile
And the problem was solved. I hope this would help someone.
Platform & Versions:
Ubuntu18.04
CUDA Version: 10.2
cuDNN Version: 7.6.5.32
driver_types.h is actually in /usr/local/cuda/targets/x86_64-linux/include
Replace the
CUDNN_INCLUDE_PATH ?= $(CUDA_PATH)/include
with
CUDNN_INCLUDE_PATH ?= $(CUDA_PATH)/targets/x86_64-linux/include
in cudnn_samples_v7/mnistCUDNN/Makefile
Assuming you are using cuda 9. In Ubuntu I put these exports in my .profile. If your .profile is empty then this is not the place to put it. You will have to figure that out yourself. This is in the cuda documentation. You will want to leave out the numbers at the beginning.
sudo nano $HOME/.profile
export PATH=/usr/local/cuda-9.0/bin${PATH:+:${PATH}}
export LD_LIBRARY_PATH=/usr/local/cuda-9.0/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
It might also be due to some 3rd party packages. In the cuda documentation it says to get these if you want to use the samples.
sudo apt-get install g++ freeglut3-dev build-essential libx11-dev libxmu-dev libxi-dev libglu1-mesa libglu1-mesa-dev
I also did a quick google search and saw on the third link something about “How To Install and Use FreeImage” it gave a library. So if the other things didn’t work try using the packages below.
sudo apt-get install libfreeimage3 libfreeimage-dev
If that doesn’t work use the Ubuntu that is supported with your cuda and cudnn version and do the things I put above. You probably don’t need to do the last one, though.
Source: https://forums.developer.nvidia.com/t/freeimage-is-not-set-up-correctly-please-ensure-freeimae-is-set-up-correctly/66950
I'm writing a program to monitor a few network switches. Today I tried added the libssh library to the project, but can't seem to get it to compile. It seems like a simple thing, but I couldn't find the answer googling.
I was able to compile a test program with the command.
gcc libssh.c -lssh
I can't seem to get the -lssh to work in my makefile.
CC=gcc
CFLAGS=-I.
LIBS=`net-snmp-config --libs` `mysql_config --cflags --libs` `-lssh`
TARGET = snmpmon
$(TARGET): $(TARGET).c
$(CC) $(CFLAGS) -o $(TARGET) $(TARGET).c $(LIBS)
clean:
$(RM) $(TARGET)
I guessing it's something simple any suggestion?
gcc -I. -o snmpmon snmpmon.c `net-snmp-config --libs` `mysql_config --cflags --libs` `-lssh --libs`
/bin/sh: 1: -lssh: not found
/tmp/cc65Loeb.o: In function `GetMACinfo':
snmpmon.c:(.text+0x26): undefined reference to `ssh_new'
snmpmon.c:(.text+0x47): undefined reference to `ssh_options_set'
snmpmon.c:(.text+0x5c): undefined reference to `ssh_options_set'
snmpmon.c:(.text+0x71): undefined reference to `ssh_options_set'
snmpmon.c:(.text+0x7d): undefined reference to `ssh_free'
collect2: error: ld returned 1 exit status
Makefile:13: recipe for target 'snmpmon' failed
make: *** [snmpmon] Error 1
OK the issue was -lssh should be -lssh the makefile didn't like the extra ` marks.
I have followed the tutorial here to build a simple nginx module with success: https://github.com/perusio/nginx-hello-world-module
I can build and run that code with no issue and it functions correctly.
I now want to add a dependancy of MySQL to the simple nginx module so I have used the MySQL C Connector http://dev.mysql.com/doc/refman/5.6/en/c-api-building-clients.html.
The simplest program you can write is this (taken from http://zetcode.com/db/mysqlc/):
mysql_test.c
#include <my_global.h>
#include <mysql.h>
int main(int argc, char **argv)
{
printf("MySQL client version: %s\n", mysql_get_client_info());
exit(0);
}
You then compile like so:
$ gcc mysql_test.c -o mysql_test `mysql_config --cflags --libs`
This works fine.
Now, when I try to include the two header files my_global.h and mysql.h with my simple nginx hello-world module, I need a way of specifying those build flags, else it won't find those header files. At the moment, when I run make, after it successfully builds all other modules, I now get:
cc -c -pipe -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs -I src/http -I src/http/modules -I src/mail \
-o objs/addon/nginx-hello-world-module/ngx_http_hello_world_module.o \
/vagrant/nginx-hello-world-module/ngx_http_hello_world_module.c
/vagrant/nginx-hello-world-module/ngx_http_hello_world_module.c:33:23: fatal error: my_global.h: No such file or directory
#include <my_global.h>
^
compilation terminated.
make[1]: *** [objs/addon/nginx-hello-world-module/ngx_http_hello_world_module.o] Error 1
make[1]: Leaving directory `/vagrant/nginx'
make: *** [build] Error 2
My question is: How do I get nginx to include those build flags when building my module?
I haven't found any information regarding the building of dependencies with Nginx.
Thanks!
Compilation Controls
--with-cc-opt=parameters
sets additional parameters that will be added to the CFLAGS variable.
--with-ld-opt=parameters
sets additional parameters that will be used during linking.
Source
For the MySQL Connector C it will be something like:
--with-cc-opt="-I/usr/include/mysql"
--with-ld-opt="-L/usr/lib64/mysql"
And in you module's config file:
CORE_LIBS="$CORE_LIBS -lmysqlclient"
During compilation it might also complain about _GNU_SOURCE being redefined and it will fail if you use -Werror without implementing a workaround.
I would like to cross compile a simple program that uses libncurses on my x86_64. Target system is MIPS.
My crosstool-ng-1.20 build went fine (with sample mips-unknown-elf)
However, a simple hello world ends badly.
#include <stdio.h>
int main(void)
{
printf("OH HAI.\n");
return 0;
}
--
x86host:~/toolchain$ mips-unknown-elf-gcc -o hello hello.c
hello.c:1:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^
compilation terminated.
I'm clearly doing something terribly wrong here, but where do i start?
[Edit]
Thank you markgz. Codesourcery is exactly what i needed.
mips-linux-gnu-gcc.exe -static -o helloStatic hello.c
Proof of concept complete. Now off to compile my ncurses program.
[Switch:/]$ file /mnt/sd3/user/helloStatic
/mnt/sd3/user/helloStatic: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1,
statically linked, for GNU/Linux 2.6.16, with unknown capability
0x41000000 = 0xf676e75, not stripped
[Switch:/]$ uname -a
Linux Switch 2.6.32.59-cavium-octeon2.cge-cavium-octeon #1
SMP PREEMPT Fri May 10 11:48:14 PDT 2013 mips64 GNU/Linux
[Switch:/]$ /mnt/sd3/user/helloStatic
HOLIDAYS ARE COMING.
You probably needed to build mips-linux-elf-gcc. Are you sure your MIPS target system is configured as big-endian?
Anyway, you can avoid all these problems by downloading the free Mentor/Codesourcery MIPS gnu/gcc cross compilation tool chain from here. This toolchain is available for both Windows and Linux.
root#x86host:~/ncurses-5.9-20141101# export CC=mips-linux-gnu-gcc
root#x86host:~/ncurses-5.9-20141101# ./configure --target=mips-linux-gnu --host=mips-linux-gnu
[..]
root#x86host:~/ncurses-5.9-20141101# make
Then, i copied over a few headers from /usr/include/ to make these go away:
root#x86host:~/ninvaders-0.1.1# make
In file included from ./ncurses.h:1685:0,
from view.h:25,
from view.c:25:
./unctrl.h:54:20: fatal error: curses.h: No such file or directory
#include <curses.h>
^
compilation terminated.
make: *** [view.o] Error 1
root#x86host:~/ninvaders-0.1.1# make
mips-linux-gnu-gcc -static -c -I. -O -Wall globals.c
mips-linux-gnu-gcc -static -c -I. -O -Wall view.c
mips-linux-gnu-gcc -static -c -I. -O -Wall aliens.c
mips-linux-gnu-gcc -static -c -I. -O -Wall ufo.c
mips-linux-gnu-gcc -static -c -I. -O -Wall player.c
mips-linux-gnu-gcc -static -c -I. -O -Wall nInvaders.c
mips-linux-gnu-gcc -static -L /root/ncurses-5.9-20141101/lib -onInvaders globals.o view.o aliens.o ufo.o player.o nInvaders.o -lncurses
root#x86host:~/ninvaders-0.1.1# ls -l nInvaders
-rwxr-xr-x 1 root root 933003 Nov 6 16:18 nInvaders
root#x86host:~/ninvaders-0.1.1# mv nInvaders nInvaders_IOSXE_MIPS
For future googlers, Makefile is:
CC=mips-linux-gnu-gcc -static
CFLAGS=-O -Wall
LIBS=-lncurses
LDFLAGS=-L /root/ncurses-5.9-20141101/lib
CFILES=globals.c view.c aliens.c ufo.c player.c nInvaders.c
HFILES=globals.h view.h aliens.h ufo.h player.h nInvaders.h
OFILES=globals.o view.o aliens.o ufo.o player.o nInvaders.o
all: nInvaders
nInvaders: $(OFILES) $(HFILES)
$(CC) $(LDFLAGS) -o$# $(OFILES) $(LIBS)
.c.o:
$(CC) -c -I. $(CFLAGS) $(OPTIONS) $<
clean:
rm -f nInvaders $(OFILES)
End result:
root#x86host:~/ninvaders-0.1.1# file nInvaders_IOSXE_MIPS
nInvaders_IOSXE_MIPS: ELF 32-bit MSB executable, MIPS,
MIPS32 rel2 version 1, statically linked, for GNU/Linux 2.6.16, not stripped
Screenshots:
http://imgur.com/a/kf8cu
https://www.youtube.com/watch?v=-qbmKYQ2jCA
I compiled my library (specifically protbuf-2.3.0) using -g -O0 on a SunOS 5.10.
A sample line in the make log is this:
/bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -pthreads -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -g -O0 -MT text_format.lo -MD -MP -MF .deps/text_format.Tpo -c -o text_format.lo `test -f 'google/protobuf/text_format.cc' || echo './'`google/protobuf/text_format.cc
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -pthreads -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -g -O0 -MT text_format.lo -MD -MP -MF .deps/text_format.Tpo -c google/protobuf/text_format.cc -fPIC -DPIC -o .libs/text_format.o
And then, I attached my gdb using the following steps:
Run my application (in this case, my web server which starts up a java web app which uses a library via jni during startup).
I attached my gdb to that process via gdb -p XXX (where XXX is the pid I got from ps).
And then I loaded my library from the gdb using file libprotobuf.so from the gdb prompt.
But I can't see my function names from bt. My GDB backtrace command shows something like this:
(gdb) bt
#0 0xf8f98914 in ?? ()
#1 0xf8f98830 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
I also tried doing #1 & #2 only, #1 & #3 only, and #1 & gdb libprotobuf.so -p XXX.
Aside from those, I also tried running my jvm on debug mode and added a breakpoint on the System.loadLibrary(..) command, and after stepping over that command, I then did the gdb attachment process again....but still nothing.
However, I am able to put breakpoints given function names and list the contents of a function via list. But then again, I can place breakpoints but they don't stop as well on those function names (I know it went to that function because it's in the jvm hs_err_pid report after every jvm crash).
Any ideas come it's not showing me my function names?
The problem is most likely in that GDB does not know how to figure out full executable path for the given PID. If it did know full path, you wouldn't need to do step #3 -- GDB would have added it automatically.
You can verify whether GDB deduced executable name correctly with (gdb) info file command.
If my guess is correct, help GDB by invoking it like this:
gdb /path/to/java <PID>
That should immediately solve all of your problems.
Additionally, be sure that the executable that uses your library isn't getting stripped somewhere.
I think that is linking problem. Can you check your command which is executed at the time of linking. Hope this will help.