I am compiling a C++ program using make, this is the error i'm getting.
/usr/bin/ld: fglut/libfglut.a(freeglut_state.o): undefined reference to symbol 'XGetWindowAttributes'
//usr/lib/i386-linux-gnu/libX11.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:55: recipe for target 'morphlines' failed
make: *** [morphlines] Error 1
I'm beginner
/usr/bin/ld: fglut/libfglut.a(freeglut_state.o):
This tells me you link libfglut statically (*.a is just an archive of object files). When you do this, you must link all dependencies as well, because with the object files from the static library actually compiled into your program, your program will depend on them.
Either link libfglut dynamically (this is the default with the GNU toolchain), so your program will depend on libfglut.so which will itself depend on libX11.so -- or add -lX11 after -lfglut on the command line of your final linking step. You might need -Wl,-Bdynamic before -lX11 to switch the linker back to dynamic linking.
If this doesn't directly solve your problem, I suggest you edit your question to include the relevant parts of the Makefile you're using.
Related
I'm trying out halide and want to build a small shared library on top of it. But the code generated by Halide's AOT compilation seems not being position independent. How do I link the objects generated by Halide into my shared library?
[Update] extracted a small example from my code.
Specifically I used a generator with c++:
class SimpleAddition : public Halide::Generator<SimpleAddition> {
public:
SimpleAddition() : vars(4) {}
Input<Halide::Buffer<>> lhs{"lhs"};
Input<Halide::Buffer<>> rhs{"rhs"};
Output<Halide::Buffer<>> out{"out"};
std::vector<Var> vars;
void generate() {
out(vars) = lhs(vars) + rhs(vars);
}
};
HALIDE_REGISTER_GENERATOR(SimpleAddition, simple_addition)
with helpers from CMake:
halide_library(ops SRCS ${CMAKE_CURRENT_LIST_DIR}/src/simple_addition.cc
GENERATOR_NAME simple_addition
GENERATOR_ARGS lhs.type=float32 lhs.dim=4 rhs.type=float32 rhs.dim=4 out.type=float32)
and got the following error:
/usr/bin/ld: ./genfiles/halide_rt_host/halide_rt_host.a(halide_rt_host.a.o): relocation R_X86_64_PC32 against symbol `_ZN6Halide7Runtime8Internal13custom_mallocE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
I also tried generating object by running the generator myself (without CMake wrapper) with -e o,h, and similarly with llvm bitcode followed by llc -relocation-model=pic, also Func::compile_to_object. similar error occurred when I try to link the generated object back to shared library:
/usr/bin/ld: halide_runtime_x86.o: relocation R_X86_64_PC32 against symbol `_ZN6Halide7Runtime8Internal13custom_mallocE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
I'm running this on Ubuntu 18.10. Both Halide and my code are compiled with gcc-8.2.0. LLVM/Clang-7 is the one shipped in their repository. Halide is built with simple cmake ../ && make && make install.
For compiler flags of my testing code, command used in CMake is add_libarary(mylib SHARED ...). Non-CMake build is with flags like -fPIC -shared, nothing special since I'm still learning.
Halide should be generating PIC by default (see Codegen_Internal.cpp, make_target_machine()). What architecture are you targeting? What compiler/linker are you using, with what options, etc?
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).
I am trying to build CEF in Release mode but I get the following linker error:
AR(target)
/home/adminuser/temp/build/linux/Release/obj.target/libcef_dll_wrapper.a
LINK(target) /home/adminuser/temp/build/linux/Release/cefclient
/home/adminuser/temp/build/linux/Release/ldb.a(ldbJS.o): In function
LdbURLLoader::LoadURL(std::string)': ldbJS.cpp:(.text+0x34e):
undefined reference toCefURLRequest::Create(CefRefPtr,
CefRefPtr)' collect2: error: ld returned 1 exit
status make: *** [/home/adminuser/temp/build/linux/Release/cefclient]
Error 1
I don't get this problem when building the Debug version so I am not quite sure how to resolve it. I tried various #pragma directives to stop the compiler from optimizing out this method but to no avail.
* UPDATE *
When I remove the -DNDEBUG flag from CFLAGS_Release in the libcef_dll_wrapper.target.mk file it will build. I don't want to do this in the Release build without knowing what I'm doing though.
I am using gcc 4.8.2.
It turns out forcing the LD linker to reanalyze my libraries was the solution. The CEF application already had an elaborate scheme of makefiles that used the --start-group and --end-group indicators to do this, but the library I previously added was not included with them. I added it and linked my application without any more problems!
I am trying to Cross Compile opencv on linux platform (ARM 8148).
I am getting following errors:
warning: libQtTest.so.4, needed by ../../lib/libopencv_highgui.so.3.0.0, not found (try using -rpath or -rpath-link)
/opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: warning: libQtCore.so.4, needed by ../../lib/libopencv_highgui.so.3.0.0, not found (try using -rpath or -rpath-link)
/opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: ../../bin/opencv_perf_core: hidden symbol `__sync_fetch_and_add_4' in /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/libgcc.a(linux-atomic.o) is referenced by DSO
/opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[2]: *** [bin/opencv_perf_core] Error 1
make[1]: *** [modules/core/CMakeFiles/opencv_perf_core.dir/all] Error 2
I am not able to understand this error and on net also not getting proper reference for that .Can anyone help me in understanding this error .
__sync_fetch_and_add_x* is normally inlined by gcc, and compiles to inline code that performs an automic operation on a memory word.
You will find them documented here:
https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/_005f_005fsync-Builtins.html
As described on this page, if the compiler emitted a function call, instead of a generating inline assembly, it means that this atomic operation is not supported on the target platform.
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.