I am having problems compiling my application with boost::managed_mapped_file without exceptions. am compiling it with the flags -DBOOST_NO_EXCEPTIONS -DBOOST_NO_EXCEPTIONS but still get
g++ -c -Wall -g -O0 -Wno-write-strings -fno-exceptions -DBOOST_NO_EXCEPTIONS -DBOOST_NO_EXCEPTIONS -I./ -I../Include/ UT_main.cpp -o UT_main.o"
In file included from /usr/include/boost/interprocess/mapped_region.hpp:18
from /usr/include/boost/interprocess/detail/managed_open_or_create_impl.hpp:17
from /usr/include/boost/interprocess/managed_mapped_file.hpp:20
from ../Include/MyMng.h:11
from main.cpp:7:
/usr/include/boost/interprocess/exceptions.hpp: In constructor interprocess_exception
/usr/include/boost/interprocess/exceptions.hpp:40: error: exception handling disabled, use -fexceptions to enable
from what i see in the code whenever the the -DBOOST_NO_EXCEPTIONS is on the interprocess/exceptions.hpp is still included but only the "include " is not included. It seems that the code should work withould exceptions.
if someone can tell me what am i missing
thanks
Compiling that library isn't supported without exceptions.
Many functions are explicitly documented (e.g. on existing files when using create_only).
The throws are unconditional (IOW it doesn't use Boost Exception's macros to replace exceptions by a user-defined callback).
For completeness: the header you see in the message fails to compile because it uses try/catch internally (to avoid exceptions during exception handling).
Related
I recently tried to build my https://github.com/eyalroz/cuda-api-wrappers/ library's examples after switching to another Linux distribution on the same machine. Strangely enough, I encountered a linking issue. The command:
/usr/bin/c++ -Wall -std=c++11 -g CMakeFiles/device_management.dir/examples/by_runtime_api_module/device_management.cpp.o -o examples/bin/device_management -rdynamic lib/libcuda-api-wrappers.a -Wl,-Bstatic -lcudart_static -Wl,-Bdynamic -lpthread -ldl -lrt
fails to find the CUDA runtime library, and I get:
CMakeFiles/device_management.dir/examples/by_runtime_api_module/device_management.cpp.o: In function `cuda::device::peer_to_peer::get_attribute(cudaDeviceP2PAttr, int, int)':
/home/eyalroz/src/mine/cuda-api-wrappers/src/cuda/api/device.hpp:38: undefined reference to `cudaDeviceGetP2PAttribute'
collect2: error: ld returned 1 exit status
but if I add -L/usr/local/cuda/lib64 it builds fine. This didn't use to happen before; and it doesn't happen on another machine I've checked on, nor does it even happen to other targets using the CUDA runtime in the same CMakeLists.txt (like version_managament).
FindCUDA seems to be finding everything, as the value of ${CUDA_LIBRARIES} is /usr/local/cuda/lib64/libcudart_static.a;-lpthread;dl;/usr/lib/x86_64-linux-gnu/librt.so. And the target lines in CMakeLists.txt are:
add_executable(device_management EXCLUDE_FROM_ALL examples/by_runtime_api_module/device_management.cpp)
target_link_libraries(device_management cuda-api-wrappers ${CUDA_LIBRARIES})
as is suggested in answers to other related questions (e.g. here). Why is this happening? Should I "manually" add the -L switch?
Edit: Following #RobertCrovella's suggestion, here are the ld search paths:
$ gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012 | tr ':' "\n" | tail -n +3
/usr/local/cuda/lib64/x86_64-linux-gnu/5/
/usr/local/cuda/lib64/x86_64-linux-gnu/
/usr/local/cuda/lib/
/usr/lib/gcc/x86_64-linux-gnu/5/
/usr/x86_64-linux-gnu/lib/x86_64-linux-gnu/5/
/usr/x86_64-linux-gnu/lib/x86_64-linux-gnu/
/usr/x86_64-linux-gnu/lib/
/usr/lib/x86_64-linux-gnu/5/
/usr/lib/x86_64-linux-gnu/
/usr/lib/
/lib/x86_64-linux-gnu/5/
/lib/x86_64-linux-gnu/
/lib/
/usr/lib/x86_64-linux-gnu/5/
/usr/lib/x86_64-linux-gnu/
/usr/lib/
/usr/local/cuda/lib64/
/usr/x86_64-linux-gnu/lib/
/usr/lib/
/lib/
/usr/lib/
$ ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu")
SEARCH_DIR("=/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/local/lib64")
SEARCH_DIR("=/lib64")
SEARCH_DIR("=/usr/lib64")
SEARCH_DIR("=/usr/local/lib")
SEARCH_DIR("=/lib")
SEARCH_DIR("=/usr/lib")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib64")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib")
Notes:
Yes, I know the CMakeLists.txt there is ugly.
TL;DR:
After the FindCUDA invocation, add the lines:
get_filename_component(CUDA_LIBRARY_DIR ${CUDA_CUDART_LIBRARY} DIRECTORY)
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} "-L${CUDA_LIBRARY_DIR}")
and building should succeed on both systems.
Discussion:
(Paraphrasing #RobertCrovella and myself in the comments:)
OP was expecting, that if the following hold:
FindCUDA succeeds
${CUDA_LIBRARIES} includes a valid full path to either the static or the dynamic CUDA runtime library
the library dependency is indicated using target_link_libraries(relevant_target ${CUDA_LIBRARIES})
... then the CMake-based build he was attempting should succeed on a variety of valid CUDA installations. That is (unfortunately) not the case, since while FindCUDA does locate the CUDA library path, it does not actually make your linker search that path. So a failure should actually be expected. The build had worked on OP's old system due to a "fluke", or rather, due to OP having added the CUDA library directory to the linker's search path, somehow, apriori.
The linking command must be issued with the -L/path/to/cuda/libraries switch, so that the linker knows where to looks for the (unspecified-path) libraries referred to be the CUDA-related -l switches (in OP's case, -lcudart_static).
This answer discusses how to do that in CMake for different kinds of targets. You might also want to have a look at man gcc (the GCC manual page, also available here) regarding the -l and -L options, if you are not familiar with them.
I use the cmake gui tool to configure my cuda project in vs2013.
CMakeLists.txt is as below:
project(CUDA_PART)
# required cmake version
cmake_minimum_required(VERSION 3.0)
include_directories(${CUDA_PART_SOURCE_DIR}/common)
# packages
find_package(CUDA REQUIRED)
# nvcc flags
set(CUDA_NVCC_FLAGS -gencode arch=compute_20,code=sm_20;-G;-g)
set(CUDA_VERBOSE_BUILD ON)
#FILE(GLOB SOURCES "*.cu" "*.cpp" "*.c" "*.h")
CUDA_ADD_EXECUTABLE(CUDA_PART hist_gpu_shmem_atomics.cu)
The .cu file is from Cuda by example source code hist_gpu_shmem_atomics.cu
There are two problems:
After the line histo_kernel <<<blocks * 2, 256 >>>(dev_buffer, SIZE, dev_histo);an "invalid device function" error occurs.
When I use the CUDA debugging tool to debug, its cannot trigger breakpoints in the device code.
But when I create a project with the same code by the cuda project temple in visual studio 2013.It works correctly!
So, is there something wrong in the CMakeLists.txt ?
OS: Win7 64bit;GPU: GTX960;CUDA: CUDA 7.5;VS: 2013 (and also 2010)
When I use set the "Code Generation" in vs2013 as follow :
The CUDA_NVCC_FLAGES turns out to be -gencode=arch=compute_20,code=\"sm_20,compute_20\"
It equals to:
-gencode=arch=compute_20,code=sm_20 \
-gencode=arch=compute_20,code=compute_20
So, I guess it will generate 2 versions machine code: the first one(SASS) with virtual and real architectures and the second one(PTX) with only virtual architecture. Since my GTX960 is a cc5.2 device, it chooses the second one (PTX) and convert it to a suitable SASS.
This is a problem:
set(CUDA_NVCC_FLAGS -gencode arch=compute_20,code=sm_20;-G;-g)
Those flags will cause nvcc to generate SASS code (only) for a cc 2.0 device (only). Such cc2.0 SASS code will not run on your cc5.2 device (GTX960). "Invalid device function" is exactly the error you would get when trying to launch a kernel in such a scenario. Since the kernel will never launch, trying to hit breakpoints in device code won't work.
I'm not a CMake expert, so there might be other, more sensible approaches, but one possible way to try to fix this might be:
set(CUDA_NVCC_FLAGS -gencode arch=compute_52,code=sm_52;-G;-g)
which should generate code for your cc5.2 device. There are undoubtedly other possible settings here, you may want to read this or the nvcc manual for more background on compile options to target specific devices.
Also note that -G generates device debug code, which is fine if that is what you want. However it will generally run slower than code compiled without that switch. If you want to debug, however, that switch is necessary.
If I try building the newest version of Caffe, it leads to this error:
$ make all
CXX/LD -o .build_release/tools/caffe.bin
clang: warning: argument unused during compilation: '-pthread'
Undefined symbols for architecture x86_64:
"caffe::Net<float>::Forward(float*)", referenced from:
test() in caffe.o
time() in caffe.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [.build_release/tools/caffe.bin] Error 1
I'm building on osx, OpenBLAS, and CPU_ONLY. I found a kind of similar issue on here but it appears to have been a resolved issue, and I'm not getting the exact same error, though perhaps it's related? I can also build and run an older version of Caffe from a month ago, so I think something has changed very recently.
Any ideas on how to overcome this error?
It shows a link problem when compile.On osx this problem will happen usually.I guess the problem happened in Makefile.config.You can change to
# To customize your choice of compiler, uncomment and set the following.
# N.B. the default for Linux is g++ and the default for OSX is clang++
CUSTOM_CXX := g++
and confirm some path is correct.
I had exactly the same problem. Its now resolved.
Do check if you already have a libcaffe.so in your system library paths (maybe /usr/local/lib). If so, delete the existing libcaffe.so and build again.
Sage is supposed to be able to create compiled code using Cython. I have never been able to get this to work. The problem appears to be with my Sage installation, since compiling fails on the included example. I don't believe I did anything special during installation, but apparently I something wrong. The Sage tutorial says
In order to make your own compiled Sage code, give the file an .spyx extension (instead of .sage). If you are working with the command-line interface, you can attach and load compiled code exactly like with interpreted code (at the moment, attaching and loading Cython code is not supported with the notebook interface). The actual compilation is done “behind the scenes” without your having to do anything explicit. See $SAGE_ROOT/examples/programming/sagex/factorial.spyx for an example of a compiled implementation of the factorial function that directly uses the GMP C library. To try this out for yourself, cd to $SAGE_ROOT/examples/programming/sagex/, then do the following:
sage: load "factorial.spyx"
When I try I get the following message:
Compiling ./factorial.spyx...
Error compiling cython file:
Error compiling ./factorial.spyx:
running build
running build_ext
building '_home_oliver_Desktop_sage_4_7_1_linux_32bit_ubuntu_10_04_lts_i686_Linux_examples_programming_sagex_factorial_spyx_0' extension
creating build
creating build/temp.linux-i686-2.6
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/local/include/csage/ -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/local/include/ -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/local/include/python2.6/ -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/local/lib/python2.6/site-packages/numpy/core/include -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/devel/sage/sage/ext/ -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/devel/sage/ -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/devel/sage/sage/gsl/ -I. -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/local/include/python2.6 -c _home_oliver_Desktop_sage_4_7_1_linux_32bit_ubuntu_10_04_lts_i686_Linux_examples_programming_sagex_factorial_spyx_0.c -o build/temp.linux-i686-2.6/_home_oliver_Desktop_sage_4_7_1_linux_32bit_ubuntu_10_04_lts_i686_Linux_examples_programming_sagex_factorial_spyx_0.o -w -O2
creating build/lib.linux-i686-2.6
gcc -pthread -shared build/temp.linux-i686-2.6/_home_oliver_Desktop_sage_4_7_1_linux_32bit_ubuntu_10_04_lts_i686_Linux_examples_programming_sagex_factorial_spyx_0.o -L/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/local//lib/ -L/home/wstein/build/sage-4.7.1/local/lib -lmpfr -lgmp -lgmpxx -lstdc++ -lpari -lm -lcurvesntl -lg0nntl -ljcntl -lrankntl -lgsl -lgslcblas -latlas -lntl -lcsage -lpython2.6 -o build/lib.linux-i686-2.6/_home_oliver_Desktop_sage_4_7_1_linux_32bit_ubuntu_10_04_lts_i686_Linux_examples_programming_sagex_factorial_spyx_0.so -L/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/local//lib
/usr/bin/ld: cannot find -lstdc++ collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
Any suggestions? Thanks.
Per DSM's comment, I reinstalled g++-multilib, and now everything works fine.
[update] How can I output the warning messages from compiler.SourceModule(kernel_code)?
With help of #flipchart I was able to pass the right parameters to NVCC trough PyCUDA, but I still don't know, where to access the compiler warnings.
[original question]
Using NVCC directly one can use the compiler switch -Wall*. How would one archive this in pycuda?
I tried mod = compiler.SourceModule(kernel_code,options=['-Wall']), but the error message states:
pytools.prefork.ExecError: error invoking 'nvcc --cubin -Wall -arch sm_11 -I/usr/local/lib/python2.6/dist-packages/pycuda-0.94.2-py2.6-linux-x86_64.egg/pycuda/../include/pycuda kernel.cu': status 255 invoking 'nvcc --cubin -Wall -arch sm_11 -I/usr/local/lib/python2.6/dist-packages/pycuda-0.94.2-py2.6-linux-x86_64.egg/pycuda/../include/pycuda kernel.cu': nvcc fatal : Unknown option 'Wall'
The source problem is, that I spent a whole day debugging, because I overlooked an inexplicit conversion fromfloat to int.
*Warnings from system-header with "--compiler-options -Wall" since CUDA 3.0
The -Wall option is not a nvcc compiler option, but rather one that is passed on to the supporting compiler (g++ or cl.exe). You need to pass in the option --compiler-options -Wall to indicate to nvcc that the option is for the supporting compiler. In you python code:
mod = compiler.SourceModule(kernel_code,options=['--compiler-options','-Wall'])
PyCuda seems to want each option specified as a list item, otherwise it wraps the whole thing in quotes which nvcc doesn't like.