In gcc, the close function is used to close the file pointer. However my nvcc complier will not allow that. I can't seem to find a cuda-specific call or alias.
Is there a special cuda file pointer close?
This is the error I get.
error: identifier "close" is undefined
For this simple code;
FILE* fp = fopen(filename,"r");
if(fp == NULL)
{
return NULL;
}
close(fp);
When NVCC compiles your .cu file, it delegates the compilation of the C/C++ parts of the file to your native C/C++ compiler (gcc in your case). So, the error is coming from gcc.
You need to check why gcc is producing this error for the code in this file. Most probably, you have not included the necessary header file where close() is defined, unistd.h. Or try fclose() as another commenter has suggested.
Related
Please look at this code:
void bar() {}
__host__ __device__ void foo()
{
bar();
}
__global__ void kernel()
{
foo();
}
int main()
{
kernel<<<1, 1>>>();
gpuErrchk(cudaPeekAtLastError());
gpuErrchk(cudaDeviceSynchronize());
return 0;
}
I spent hours trying to solve the an illegal memory access was encountered runtime error. As it turned out, the reason is the bar() function - it's not declared as __device__. But! But the code compiles! It produces a warning, but compiles! The warning says:
warning: calling a __host__ function("bar") from a __host__ __device__
function("Test::foo") is not allowed
Since the compilation for my project produces a lot of output, I simply didn't see that warning. But if I remove the __device__ attribute from the foo() function, I get the expected error:
error: identifier "foo" is undefined in device code
The question is why the compiler prints only a warning and how to turn it into an error?
The question is why the compiler prints only a warning and how to turn it into an error?
The compiler prints only a warning because it doesn't know (at the point of compilation of the calling function) if the function will actually be called at runtime, in the objectionable configuration (i.e. on or from device code).
and how to turn it into an error?
From the nvcc manual you can add either:
-Werror all-warnings
to flag all warnings as errors
or
-Werror cross-execution-space-call
to only flag this type of warning as an error.
Also see here. To those who will ask why I didn't flag as a dupe, that other question doesn't include a question (or in the answer itself) about why the compiler behaves this way.
I spent hours trying to solve the... error. ... But the code compiles! It produces a warning, but compiles!
You need to revisit your debugging methodology right there :-(
Any warning which you have not positively proven to yourself is immaterial - is where you need to look for your errors. And it is far easier and more rewarding to resolve warnings than to prove them invalid. (And by resolve, I mean address the underlying condition, not suppressing the warning, or const_cast'ing etc.)
So, don't turn warnings into errors with the compiler, turn them into essentially-errors in your mind. Clean, warning-free code = happy life.
I am working on a CUDA C++ project that uses separable compilation, and I am having some trouble getting a thrust function to compile.
The project builds with no problem until the following function call is added.
thrust::device_ptr<float> max_int = thrust::max_element(
thrust::device_ptr<float>(dev_temp_intensity_buffer),
thrust::device_ptr<float>(dev_temp_intensity_buffer + INT_BUF_SIZE);
As said, I get the build error:
Severity Code Description Project File Line Suppression State
Error LNK2019 unresolved external symbol __fatbinwrap_66_tmpxft_00006db0_00000000_18_cuda_device_runtime_compute_61_cpp1_ii_8b1a5d37 referenced in function __cudaRegisterLinkedBinary_66_tmpxft_00006db0_00000000_18_cuda_device_runtime_compute_61_cpp1_ii_8b1a5d37 visualize C:\Users\13\Google Drive\WireMeshOT Rafael\CUDA\simulator\build\src\visualize_intermediate_link.obj 1
The funny thing is that this other thrust function call compiles just fine:
thrust::exclusive_scan(thrust::device_ptr<unsigned int>(dev_ray_alive),
thrust::device_ptr<unsigned int>(dev_ray_alive + NRAYS),
thrust::device_ptr<unsigned int>(dev_scanned_alive_rays));
Obs1: dev_temp_intensity_buffer is a float device pointer, and I am including thrust/extrema.h and thrust/device_ptr.h.
Obs2: I am using CMake to configure the build. The relevant CMake code excerpts are shown below.
SET(CUDA_SEPARABLE_COMPILATION ON)
set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} -rdc=true -D_FORCE_INLINES)
set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} -arch=compute_52 -code=sm_52 -lcudart -lcudadevrt -lcuda)
set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} -Xptxas -v)
cuda_add_executable(
project
file1.cu
...)
target_link_libraries (project glut glew)
I finally figured it out!
The linking problem was due to the fact that cudadevrt library was missing. The catch is that only adding -lcudadevrt to the CUDA_NVCC_FLAGS was not enough!
The problem goes away when linking the CUDA runtime device library to the CMake target as shown below:
target_link_libraries(project glut glew ${CUDA_cudadevrt_LIBRARY})
Obs1: the CUDA_cudadevrt_LIBRARY variable is only made available on CMake versions above 3.7.2. Adding the line cmake_minimum_required(VERSION 3.7.2) is a good idea.
Obs2: linking only to CUDA_LIBRARIES as below does solve the issue only if you are using a CMake version above 3.7.2. On lower versions this variable exist but does not contain cudadevrt library.
target_link_libraries(project glut glew ${CUDA_LIBRARIES})
Since I made some progress, I changed the title and made a second edit describing my new problem. You may choose to ignore Edit1
I have been trying to run python code from C code. And for this purpose I have been using Cython.
The semantics of my system is such that there is a binary (whos source I can not access) that calls a C function defined in a file (source is accessible) and within this function I need to call python functions, do some processing and return the result to binary.
To achieve this purpose, there are two approaches that I came across:
http://docs.python.org/release/2.5.2/ext/callingPython.html ===> This approach suggests to have the python callback function passed to the C side, so that the callback is called as necessary, but this doesn't work for me as I don't have access to the binary's source (which is used to run the entire system)
https://stackoverflow.com/a/5721123/1126425 ==> I have tried this approach and I get this error when the cython function is called:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb47deb70 (LWP 2065)]
0x007fd38a in PySys_GetObject () from /usr/lib/libpython2.6.so.1.0
http://www.linuxjournal.com/article/8497?page=0,0 ==> This is in fact the basis for cython's functionality but again when I use the examples described there, I get errors similar to 2.
I have no idea how to resolve these errors. Any help would be much appreciated.
Thanks!!
Edit1:
here is a simple scenario that reflects situation:
external.c
#include <external.h>
int callback(int param1,int param2)//Function that the binary calls
{
/*SomeTasks*/
cython_func();//Function defined in the following .pyx file
/*SomeTasks*/
}
cython_file.pyx
cdef void cython_function():
print "Do Nothing!"
I am linking the shared library file created by cython with the library generated by compiling the above C code and then that library is used by the binary...
Edit2:
The segmentation fault goes away when I added Py_Initialize(); before calling cython_function(). But now I am getting the undefined symbol error as : symbol lookup error: lib_c_code.so: undefined symbol: cython_function
Here lib_c_code.so is the shared library created out of the external.c file above. I have tried including the .h file created by the cython compiler in external.c but it still didn't work out.. Here is how I am compiling lib_c_code.so:
gcc -shared -dynlib -lm -W1 -o lib_c_code.so $(OBJDIR)/*.o -lc -lm -lpy_code
and the libpy_code.so is the shared object file that was created out of the cython_file.pyx file as:
cython cython_file.pyx -o cython_file.c
gcc $(IFLAGS) -I/usr/include/python2.6 -fPIC -shared cython_file.c -lpython2.6 -lm -o libpy_code.so
Also, I can see the symbol cython_function in the lib_c_code.so file when I do : nm -g lib_c_code.so..
Any ideas please?
I have to guess here that there's a callback registration function to which you can pass the function pointer, in which case you can simply forego the C file and define a cdef function directly in your Cython code, and pass that with the callback registration function. Use with gil in case you manipulate any Python objects in it.
cdef extern from "external.h":
ctypedef int (*Cb_Func)(int param1, int param2)
void register_callback(Cb_Func func)
cdef int my_callback(int param1,int param2) with gil:
<implementation>
register_callback(my_callback)
This is also explained in the Cython user manual here: http://docs.cython.org/src/userguide/external_C_code.html
I tried messing around with Win32 binaries lately (this is for a big project of mine).
So after some weeks of research, I now have a solid understanding of how Assembly works, how it is converted into binary code and how x86/x64 opcodes work.
The last piece to the puzzle is figuring out how to properly call Win32 API methods.
I actually asked a question on here in relation to this, and the answer I got was, I should try and compile an Assembly or C program that does this. So I went ahead and tried this in Assembly (I'm using FASM by the way):
format PE console
entry start
section '.idata' import data readable writable
include 'win32a.inc'
library kernel,'kernel32.dll'
import kernel,\
GetStdHandle,'GetStdHandle',\
WriteConsoleA,'WriteConsoleA'
section '.data' data readable writable
string db 'Hello!', 0h
output dd ?
section '.code' code readable executable
start: push -11
call GetStdHandle
pushd 0
pushd output
pushd 7
pushd string
pushd eax
call WriteConsoleA
This is one of the many versions of this code actually. The main problem is, when I call methods like "ExitProcess", generally other functions from the kernel32.dll library, things seem to work out. It's the IO functions that bug me...
I don't understand what's wrong with this code, I don't get any compile-time errors, though when I run it, it just crashes.
So my next idea was, since this didn't work, to try the same in C.
I'm using Cygwin as a compiler and linker...
#include <windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
MessageBox(NULL, "Hello, world!", "Test", MB_OK);
return 0;
}
This code yielded the same result, the application crashed.
Now, I am not looking for any C/C++ code. My original question of interest was to know how calling extern library function looks like in x86/x64 binary (assembled) code. But I would be very thankful for any resources regarding this topic.
Thank you in advance.
-Tom S.
Your problem is that you need to call ExitProcess at the end to properly end the process. Since you are not doing that, the code currently will continue executing and eventually segfaults because it attempts to execute junk bytes.
I'm trying to compile/port an older version of OpenOffice. It uses Boost v1.34.1, which is part of the source tree. The error message is as follows:
Undefined symbols:
"boost::throw_exception(std::exception const&)", referenced from:
boost::detail::shared_count::shared_count<ScToken>(ScToken*)in detfunc.o
ld: symbol(s) not found
Boost is new to me, and I haven't been able to find much online to help me understand this. From the error message, I understand that I probably need to link a library. However, boost::throw_exception is defined in a header file with no matching library (that I can find). Just for kicks, I've tried #include <boost/throw_exception.hpp> in detfunc and using symbolic links to put the header file in the same directory with no luck.
Is there a library I should be linking with -l or an include path with -I? How should I get that symbol referenced in?
Boost expects the project either to be built with macro BOOST_NO_EXCEPTIONS undefined, or to define the function boost::throw_exception itself.
From <boost/throw_exception.hpp> in version 1.34.1:
namespace boost
{
#ifdef BOOST_NO_EXCEPTIONS
void throw_exception(std::exception const & e); // user defined
#else
//[Not user defined --Dynguss]
template<class E> inline void throw_exception(E const & e)
{
throw e;
}
#endif
} // namespace boost
Boost's configuration headers will determine whether to define the macro or not. It looks like it boils down to the compiler you're using, but there may be other factors. Take a look in the boost/config/compiler/ folder for the header file that corresponds to your compiler, then search for BOOST_NO_EXCEPTIONS in it. There should be some conditions around the #define to help explain when Boost defines it. You may be able to configure your build to avoid the definition and get past the linker error you're experiencing.
If you're unable to change your compiler config to avoid the definition, then you're probably left defining boost::throw_exception(std::exception const & e) yourself somewhere in the OpenOffice code. I'm unfamiliar with that code, though, so I can't give a good suggestion where it should go.