I have a question regarding the inclusion of boost libraries to make files. This question has been asked (and answered) multiple times in this forum and others, I could not solve my problem however using suggestions from there, since I am stuck in a much more basic stage.
I am using a ready made make file that includes the address of the boost libraries via an env file that is included in the beginning of the makefile. Thus, all I have to do is provide the correct folder of the boost libraries, however I seem to be providing the wrong address, as I get an error that the boost libraries could not be found:.
Demo_00.cpp:(.text+0x28): undefined reference to `boost::mpi::environment::environment(int&, char**&, bool)'
Demo_00.cpp:(.text+0x34): undefined reference to `boost::mpi::communicator::communicator()'
Demo_00.cpp:(.text+0x40): undefined reference to `boost::mpi::communicator::rank() const'
Demo_00.cpp:(.text+0x55): undefined reference to `boost::mpi::communicator::rank() const'
Demo_00.cpp:(.text+0x8b): undefined reference to `boost::mpi::environment::~environment()'
Demo_00.cpp:(.text+0xb3): undefined reference to `boost::mpi::environment::~environment()'
collect2: ld returned 1 exit status
The specific part of the env file looks like this:
BOOST_INCLUDE=-I./home/user/Documents/RHPC_2.0/INSTALLATION/boost_1_54_0/
BOOST_LIB_DIR=-L./home/user/Documents/RHPC_2.0/INSTALLATION/boost_1_54_0/stage/lib
BOOST_LIBS=-lboost_mpi-xgcc42-mt -lboost_serialization-xgcc42-mt -lboost_system-xgcc42-mt -lboost_filesystem-xgcc42-mt
My questions:
In the template file of the env file, the first address ended with '.../boost_1_54_0/include', my boost folder does not have an include folder however (there are some further within the folder only). Is this a problem?
Do I need to make any adjustment to BOOST_LIBS?
Is there maybe a simple way of identifying the correct addresses using cmake? I worked my way through the cmake documentary but did not quite get how this would be implemented.
Also: I have just tried to 'compile+link' by hand, which only worked for the compiling part but not for linking. Here is the compiling:
/home/user/Documents/RHPC_2.0/INSTALLATION/mpich2-1.4.1p1/bin/mpicxx -c -I/home/user/Documents/RHPC_2.0/INSTALLATION/boost_1_54_0/ -o Demo_00.o Demo_00.cpp
Here is the Linking part, which did not work
/home/user/Documents/RHPC_2.0/INSTALLATION/mpich2-1.4.1p1/bin/mpicxx -L/home/user/Documents/RHPC_2.0/INSTALLATION/boost_1_54_0/stage/lib/ Demo_00.cpp -lboost_mpi-xgcc42-mt -lboost_serialization-xgcc42-mt -lboost_system-xgcc42-mt -lboost_filesystem-xgcc42-mt
After this command I get the following error:
/usr/bin/ld: cannot find -lboost_mpi-xgcc42-mt
/usr/bin/ld: cannot find -lboost_serialization-xgcc42-mt
/usr/bin/ld: cannot find -lboost_system-xgcc42-mt
/usr/bin/ld: cannot find -lboost_filesystem-xgcc42-mt
collect2: ld returned 1 exit status
It seems, here the problem lies with the these last 4 files and not the entire boost folders. The above folders /usr/bin/ld are also not existent to my knowledge.
I appreciate your help and again my apologies for bringing up this topic yet again.
Thanks,
Tartaglia
Whatever is passed to -I should be pointing to the folder having boost/*hpp files under it (say boost/shared_ptr.hpp).
Whatever is passed to -L should be the folder where all of those passed to -l reside (when you say -lthename the respective file name is libthename.so).
Also these BOOST_* environment variables should be concatenated to the compiler/linker command line (I assume that is already happening automatically in your case).
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've built my code on a machine with gcc 6.3 before. I'm building the same code on another machine with gcc 5.3. I tried using the working oed library from a different location. But still the error persists. I went through suggestions in other questions similar to this on Stackoverflow, but they suggest that the library must be already linked. This is not the case though.
Oed is a fortran library and the code is in C and C++.
I'm at a loss to think how to figure out this problem. Any help is welcome.
/usr/bin/ld: oed__gener_nai_batch.o: access beyond end of merged section (380)
/usr/bin/ld: oed__gener_nai_batch.o: access beyond end of merged section (586)
/usr/bin/ld: oed__gener_nai_batch.o: access beyond end of merged section (580)
/usr/bin/ld: /home/umunipala/gamess/gamess-kris-simgms/simgms/oed/liboed.a(oed__gener_nai_batch.o)(.debug_info+0x203): reloc against `.debug_str': error 2
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
Well, there are two solutions I think.
recompile the .c file with your current library settings.
export a corresponded version LD library.
The problem is basically caused by the disagreement between .o file and your gcc(compiler).
While building glibc, I get this error.
*glibc/build/elf/dl-allobjs.os: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status*
What is an .os file and what binutil do I need to install to fix this?
What is an .os file
It's just an object file, intended to be linked into a shared library. UNIX linkers for the most part don't care about file extension, you can call file foo.o, foo.oS, or just about anything else, it would still work.
what binutil do I need to install to fix this?
It's unlikely that your problem has anything to do with binutils. It is more likely that the file got corrupted somehow.
What does file glibc/build/elf/dl-allobjs.os report? Are you cross-compiling? Does the problem reproduce if you reconfigure and rebuild in a different directory?
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.
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.