I am stumped by what seems to be a problem that should be easy to diagnose and fix. I have a C++ source file that makes use of the CUDA Driver API. When I compile it using nvcc, the executable is produced and works without problems. However, when I try to compile it using g++, the linker complains about undefined references to symbols that are in /usr/lib/libcuda.so:
undefined reference to cuDeviceGet'
... undefined reference tocuDeviceComputeCapability'
... undefined reference to cuDeviceGetName'
... undefined reference tocuDeviceTotalMem_v2'
... undefined reference to cuDeviceGetAttribute'
... undefined reference tocuDeviceGetAttribute'
... undefined reference to cuDeviceGetAttribute'
... undefined reference tocuDeviceGetAttribute'
I tried to ensure that /usr/lib is included in the library path (by supplying the flags -L/usr/lib, -lcuda, and adding /usr/lib to $LIBRARY_PATH). However, the problem still persists. I am sure that /usr/lib/libcuda.so contains the symbols that the linker is complaining about:
$ nm -D /usr/lib/libcuda.so | grep cuDeviceGet
00000000000be410 T cuDeviceGet
00000000000bf120 T cuDeviceGetAttribute
00000000000d2e10 T cuDeviceGetByPCIBusId
00000000000be200 T cuDeviceGetCount
00000000000bdfa0 T cuDeviceGetName
00000000000d2bb0 T cuDeviceGetPCIBusId
00000000000bf380 T cuDeviceGetProperties
I find it strange that nvcc successfully compiles the file, but g++ does not. Do you have any idea as to how I can fix this problem?
Thank you very much for your help!
Ok, the reason I was not able to compile the file was because the -lcuda flag has to come after the filename. Otherwise, it won't work... a large, prominent warning with the compiler telling me this information would have been much appreciated. Well, that was a waste of two hours.
Related
I have a boost module called arachne, when importing this module in a python script called submitArachne I get the follwoing error: Kolophon/shlib/arachne/arachne.so: undefined symbol: _ZNK5boost15program_options22error_with_option_name4whatEv
I was not able to find any documentation from boost regarding this error. Since this is a undefined symbol error, I feel like this is a compiler problem / linker problem. I set the linker flags as follows:
BOOSTLIBS = -L$(BOOSTLIB_DIR)
BOOSTLIBS += -lboost_python39 -lboost_program_options -lboost_filesystem -lboost_system
MYLIBS += $(PYTHONLIBS) $(BOOSTLIBS)
I am currently using gcc/8.3.0 and Boost/1.78.0. The python version is Python/3.9.12.
I was not able to find any possible solutions/documentation regarding this error. I hope that someone has an idea what could be going wrong here.
I already played a little bit with the linker flags but I was not able to find a solution to this unique problem.
I am trying to link ICU 57 to my binary file. That does not work even thought (I think at least) I am linking the static lib files.
Here is a blunt example:
gcc -static /usr/lib/libicui18n.a /usr/lib/libicuuc.a /usr/lib/libicudata.a /usr/lib/libicule.a /usr/lib/libiculx.a /usr/lib/libicutu.a /usr/lib/libicuuc.a /usr/lib/libicuio.a obj/ex.o obj/msg.o -o bin/ex
This is the error message that I get:
src/msg.c:5: undefined reference to `u_fopen_57'
src/msg.c:9: undefined reference to `u_fgetfile_57'
src/msg.c:10: undefined reference to `u_fgetfile_57'
src/msg.c:11: undefined reference to `u_frewind_57'
src/msg.c:18: undefined reference to `u_fgetc_57'
src/msg.c:17: undefined reference to `u_feof_57'
src/msg.c:25: undefined reference to `u_fclose_57'
Linking the dynamic libs works fine though.
If you can, I'd recommend using pkg-config as I recommended here,
specifically with pkg-config --static … as explained here
I try to use a library compiled with gcc called matlisp based on fortran code. After specifyng the f77 compiler, I could performed the autoreconf, configure and make command to obtain the file libmatlisp.so.
But when I try to use it i get a:
Error opening shared object ".../libmatlisp.so":
/usr/lib/libf2c.so.2: undefined symbol: MAIN__.
And when i perform the command ld libmatlisp.so i get:
...
libmatlisp.so: undefined reference to `idamax_'
libmatlisp.so: undefined reference to `dger_'
/usr/lib/libf2c.so.2: undefined reference to `MAIN__'
libmatlisp.so: undefined reference to `zscal_'
libmatlisp.so: undefined reference to `dscal_'
....
Is there a way to improve the situation?
I already try this solution but it does not work.
I also try to change the compiler to gfortran but i get some some run time error messages mentionning missing libraries that are part of libf2c.
Ok. I move to a more recent source of matlisp 2012 instead of 2003, and it run properly in my environment now.
I have been writing some python extension modules with cython. The extensions I've written build and work well. Then, I wanted to use typed memoryviews, when accessing my numpy arrays, as they seem to have several advantages http://docs.cython.org/src/userguide/memoryviews.html
However, as soon as I use a memoryview in my cython code I will get an error when building the extension. For example, if I add this test line:
cdef double[:, ::1] X = np.zeros((100, 100))
to an existing, working cython extension. I will get the following errors:
C:\MinGW\bin\gcc.exe -shared -s build\temp.win32-2.7\Release\image_box.o build\temp.win32-2.7\Release\image_box.def -Lc:\python27\libs -Lc:\python27\PCbuild -lp
ython27 -lmsvcr90 -o x:\ARframework\python\image_ops\image_box.pyd
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0xe23): undefined reference to `___sync_fetch_and_add_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x3318): undefined reference to `___sync_fetch_and_add_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x4c81): undefined reference to `___sync_fetch_and_sub_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x4d37): undefined reference to `___sync_fetch_and_sub_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x10767): undefined reference to `___sync_fetch_and_sub_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x10793): undefined reference to `___sync_fetch_and_sub_4'
collect2.exe: error: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
I've tried to add -march=i486 to the gcc line, as suggested in this post:
undefined reference to sync_fetch_and_add_4
but that didn't solve the problem. For that matter, I also tried -march=i586 and -march=pentium without success.
Any idea what's going on here?
My platform is Windows 7, mingw version is 4.70, Cython version is 0.17.1
Thanks
I found a solution.
Actually, the gcc flag -march=i486 does solve the problem! However, when I tested it in the console I just applied it to the gcc line for the link step (that's where I got the errors) and as it didn't solve the problem I thought it just didn't work.
In fact, I need to use -march=i486 both in the compile and link steps, then there is no errors anymore.
As to how to include these flags when I build the extension, I have tried to add
import os
os.environ['LDFLAGS'] = '-march=i486'
os.environ['CFLAGS'] = '-march=i486'
to the setup.py but it didn't seem to work.
So I have modified the c:\python27\Lib\distutils\cygwinccompiler.py to include these flags in the compile and link steps. Not sure if this is very elegant way of setting these flags. Any alternatives are welcome!
This is on a fairly fresh vanilla Win7 64-bit installation with the latest MinGW64, in a clean (freshly extracted) GLFW 2.7.5 source directory calling their make win32-msys command.
[A] Building the libs
#1 -- Warning at gcc -c -I. -I.. -Wall -mwin32 -O2 -o win32_init.o win32_init.c:
win32_init.c: In function '_glfwPlatformTerminate':
win32_init.c:353:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#2 -- Warning at gcc -c -I. -I.. -Wall -mwin32 -O2 -mdll -DGLFW_BUILD_DLL -D_GLFW_NO_DLOAD_GDI32 -D_GLFW_NO_DLOAD_WINMM -o win32_init_dll.o win32_init.c:
win32_init.c: In function '_glfwPlatformTerminate':
win32_init.c:353:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
But the relevant output files do get created in .\lib\win32: glfw.dll, libglfwdll.a and libglfw.a. However I worry those might be corrupted, since it's impossible for me to link to them via gcc later on -- same problem as the last one in this post described further down.
[B] Building the examples
#3 -- Warning at triangle.exe, pong3d.exe, splitview.exe, mipmaps.exe, gears.exe, boing.exe, wave.exe, heightmap.exe:
c:/mingw64/x86_64-w64-mingw32/bin/ld.exe: warning: cannot find entry symbol _mainCRTStartup; defaulting to 0000000000401000
Not so however for listmodes.exe, mthello.exe, mtbench.exe and particles.exe which build fine. Indeed those 4 are the only ones running properly here afterwards, the others just exit immediately without outputs or errors (naturally, since there is no valid entry point for them).
[C] Building the tests
Warning at accuracy.exe, dynamic.exe:
c:/mingw64/x86_64-w64-mingw32/bin/ld.exe: warning: cannot find entry symbol _mainCRTStartup; defaulting to 0000000000401000
No such problem for defaults.exe. For dynamic.exe it then proceeds with the following errors:
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x1c): undefined reference to `__imp_glfwGetVersion'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x62): undefined reference to `__imp_glfwInit'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0xcf): undefined reference to `__imp_glfwOpenWindow'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x10b): undefined reference to `__imp_glfwSetWindowTitle'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x118): undefined reference to `__imp_glfwSetWindowSizeCallback'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x123): undefined reference to `__imp_glfwSwapInterval'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x14a): undefined reference to `__imp_glfwGetWindowParam'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x151): undefined reference to `__imp_glfwSwapBuffers'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x174): undefined reference to `__imp_glfwTerminate'
collect2: ld returned 1 exit status
make[1]: *** [dynamic.exe] Error 1
make[1]: Leaving directory `/c/glfw64/tests'
make: *** [win32-msys] Error 2
Now this latter one is the test program for loading the DLL. You might think that's simply missing the necessary libs (.a and .dll) in the correct places, but do note at this very point I DID have all the necessary includes and libs (from an earlier GLFW make that was exactly the same as the above, same versions, same warnings, same output files) in the correct places:
libglfwdll.a in \MinGW64\x86_64-w64-mingw32\lib (next to libglu32.a, libopengl32.a)
glfw.h in \MinGW64\x86_64-w64-mingw32\include\GL (next to gl.h, glaux.h, glu.h)
glfw.dll in \windows and \windows\system32 (next to opengl32.dll, glu32.dll)
Problem A is harmless but I've added an additional cast to remove the warning. Problems B and C are due to two bugs in GLFW. They have now been fixed, in part thanks to this thread. Thanks for posting it to the GLFW bug tracker and so bringing them to my attention. The fixes will be included in the 2.7.6 release. Until then, you can grab trunk from the GLFW Subversion repository.
Problem C was tricky enough to solve that someone may find a summary useful.
Proper linking for 32-bit requires a .def file with __stdcall decorated symbols, but this file cannot be used for 64-bit. The solution was to have GCC generate the correct .def file for the given architecture.
This is done by linking the DLL twice. First it's linked as exporting __stdcall decorated symbols (the default) and generating the .def file (using -Wl,--output-def,file.def) and then it's linked again without decorations (using --kill-at) to produce the final DLL. This generated .def file can then be used as usual with dlltool to generate the import library.
The most useful resource I found whilst researching this was Stdcall and DLL tools of MSVC and MinGW, which among other things outlines this method.
I got the same error too.
Solved by change the file glfw-2.7.5\tests\Makefile.win32.mingw:12 from
SOLIB = ../lib/win32/libglfwdll.a
to
SOLIB = ../lib/win32/glfw.dll
I ran into the exact same problem and while researching the errors and warning I found a fix for the 'cannot find entry symbol error' warning:
In examples/Makefile.win32.msys and tests/Makefile.win32.msys change the line
WINDOWS = -mwindows -e _mainCRTStartup
to
WINDOWS = -mwindows
Kabie's fix helps with the dynamic linking error
I'm not 100% sure this is a correct solution as I don't completely understand the reason for the alternate entry point name in the first place but at least the tests seem to work and the examples run.