A co-worker ran into a linker warning while linking something in Solaris:
ld: warning: symbol 'vtable for boost::system::error_category::std_category' has differing sizes:
(file blah.o value=0x24; file (...)/libboost_system.a(error_code.o) value=0x14
blah.o definition taken
... where the [apparently] offending code exists in boost/system/error_code.hpp. This happens when compiled with -std=c++11, but not with -std=c++98.
It should've been obvious from the beginning but I was being dense. We recently switched from C++98 to C++14, but the boost libraries were built with the compiler's default -- C++98.
Related
I get a strange linker error when building a project (which uses GStreamer 1.0 and therefore depends on Glib 2.0) with cmake and linking against glib library. Glib is installed using macports, libglib-2.0.0.dylib is present in /opt/local/lib/. FindGLIB successfully finds its header files (compiling works) and also ${GLIB_LIBRARIES} provides the right path to the library.
The error message is
[100%] Linking CXX executable ../bin/presenter
Undefined symbols for architecture x86_64:
"_g_object_set", referenced from:
...
"_g_type_check_instance_cast", referenced from:
...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
If I remove glib from the list completely it's also copmplaining about missing reference to g_print and g_printerr. Is it possible that the linking is done correctly but the functions are just missing for some reason inside the library?
How can I fix it?
Finally found my mistake. When using FindGLIB of the Webkit project, it by default searches only for the main glib library. It's components have to be passed in addition to be found:
find_package(GLIB COMPONENTS gobject REQUIRED)
would find glib itself and save it in ${GLIB_LIBRARIES} and also gobject and save it in ${GLIB_GOBJECT_LIBRARIES} so they can be used in target_link_libraries()
Reminder: Always read the comments in the file headers - they often contain useful information...
# Optionally, the COMPONENTS keyword can be passed to find_package()
# and Glib components can be looked for. Currently, the following
# components can be used, and they define the following variables if
# found:
#
# gio: GLIB_GIO_LIBRARIES
# gobject: GLIB_GOBJECT_LIBRARIES
# gmodule: GLIB_GMODULE_LIBRARIES
# gthread: GLIB_GTHREAD_LIBRARIES
After compiling clang and llvm following the instruction on the llvm website I try linking to the built static libs in a test app. All code is built with v110 of the VS toolset. Im getting linker errors of type "error LNK2001" and "error LNK2019".
The app appears to put the libs in the bucket for symbol resolution. With verbose linker output i can see that they are just being dismissed:
1> Unused libraries:
...
1> C:\Sdk\llvm\Debug\lib\clangTooling.lib
...
Digging a little deeper i have found that the symbols in the error message and the ones in the libs are not quite the same.
-Here is an example-
Linker error =>
*unresolved external symbol "public: int __cdecl clang::tooling::ClangTool::run(class clang::tooling::ToolAction )" (?run#ClangTool#tooling#clang##QEAAHPEAVToolAction#23##Z) referenced in function main
...giving "?run#ClangTool#tooling#clang##QEAAHPEAVToolAction#23##Z" as the symbol name.
Now using "dumpbin /SYMBOLS" on my built version of the clangTooling.lib =>
*FDA 00000000 UNDEF notype () External | ?run#ClangTool#tooling#clang##QAEHPAVToolAction#23##Z (public: int __thiscall clang::tooling::ClangTool::run(class clang::tooling::ToolAction ))
... i can see the the symbol im looking for is called
"?run#ClangTool#tooling#clang##QAEHPAVToolAction#23##Z"
There is a very subtle difference near the beginning of the address. Here they are again side by side for comparison.
?run#ClangTool#tooling#clang##QEAAHPEAVToolAction#23##Z << Error Message
?run#ClangTool#tooling#clang##QAEHPAVToolAction#23##Z << Dumpbin Output
Why is it that these do not match?
Thanks
So it turns out the LLVM/clang libraries I had built were 32 bit while my test project was building 64 bit. I have successful built a test project using 32 bit binaries. The notes on this answer Unresolved Externals in C++: Visual C++ mangles method signature differently from mangled method in dll describe the issue in more detail.
*Note for anyone else looking into linking with LLVM libs. The CMake documentation for LLVM/clang (found here http://llvm.org/docs/CMake.html) makes it sound like it defaults to 64 bit on a 64 bit system. On Windows7 64bit/VisualStudio11 (at least on my machine) this isnt the case. I haven't yet found an option to support 64 bit compilation from the CMake menu. For now it seems the only option is to embed into 32 bit apps.
I have a symbol that is being referenced in an Xcode dynamic library target, but it is not defined there. I NEED this symbol to be undefined. This is because it will be compiled differently in each process that includes it (based upon some compile time defines).
The dynamic library target in Xcode that fails to link because it contains a reference to this symbol (which is not unexpected), but I know that the symbol will be available at run time. I will be compiling this function into each target that the common library is linked to.
I am trying to get the linker to mark this particular symbol for dynamic lookup at run time.
I have been able to get it to link if I specify "-undefined dynamic_lookup" as one of the "Other Linker Flags" in my Xcode project. The problem is that I don't want to go that far. I know that only 1 symbol is supposed to be undefined. I want all the rest of the symbols to generate errors if they are left as undefined (I want to avoid a run time missing symbol error basically).
I found a ld linker option that seems like it should do what I need (from ld man page):
-U symbol_name
Specified that it is ok for symbol_name to have no definition. With -two_levelnamespace, the resulting symbol will be marked dynamic_lookup which means dyld will search all loaded images.
However, I cannot seem to get it to work. Whenever I specify "-U symbolName" or "-UsymbolName" in the "Other Linker Flags" I am still greeted with this linker error:
Undefined symbols for architecture x86_64:
"_symbolName", referenced from: <various object files>
Am I using -U incorrectly perhaps? Is it not really the option I need, or is it just not working like it is supposed too?
Set -Wl,-undefined,dynamic_lookup to OTHER_LDFLAGS.
Link: Xcode clang link: Build Dynamic Framework (or dylib) not embed dependencies
Setting -Wl,-undefined,dynamic_lookup is dangerous, since it disables all undefined warning.
Use -Wl,-U,symbol_namein OTHER_LDFLAGS to disable warnings for a single symbol.
In Xcode:
Go to Project/Select Target
Click Build Settings
Search Other Linker Flags
Enter options
I have successfully built and installed latest binutils-2.22 on Solaris 10.
But when I try to use the installed programs such as ld and or I get a run-time error:
ld.so.1: ld: fatal: relocation error: file /home/pernord/alt/bin/ld: symbol __clz_tab: referenced symbol not found
I have search extensively for the error but all the hits seems unrelated to my problem.
From what I have read __clz_tab seems related to 'libgcc`.
At least libgcc contains the symbol clz.
strings /lib/*/libgcc* | grep clz
Ideas anyone?
__clz_tab is a table in libgcc used to implement a CLZ ("count leading zeros") function.
Do your binutils executables depend on libgcc_s.so? What does ldd /home/pernord/alt/bin/ld show?
If libgcc_s.so isn't in your library search path you might need to use crle(1) to add it.
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.