LLVM/Clang 3.8 unresolved external symbol __readgsqword - windows

I'm trying to compile the following code in clang 3.8.0 for windows (pre-built)
int main()
{
__readfsdword(0x30);
__readgsqword(0x60);
return 0;
}
and I'm getting the following link error
error LNK2019: unresolved external symbol __readgsqword referenced in
function main
any idea why the call to __readfsdword compiles and links fine but the call to __readgsqword does not?
I'm using the -m64 compilation flag to build a 64bit binary, and __x86_64__ preprocessor flag which should enable the use of __readgsqword according to \lib\Headers\Intrin.h
I get the same error on both x86 and x64 versions of clang.
any help will be appriciated

I don't know if you solved your problem, but I will post an answer for future readers.
Just #include <intrin.h> in your project. No need to copy Clang's Intrin.h. Windows SDK provides that header.

Related

Libtorrent 1.1 unresolved external symbol if_nametoindex

I am trying to make works libtorrent on VS2015 with boost 1.60. I built both and trying to build example "simple_client" from libtorrent but unfortunately it shows me:
unresolved external symbol if_nametoindex (broadcast_socket.obj)
Any ideas?
the if_nametoindex function is defined in iphlpapi.dll. See the documentation on msdn.

GOBJECT : unresolved externals symbol ___chkstk_ms

On compiling GOBJECT in Visual Studio, I came across below two
errors:
Error 5 error LNK1120: 1 unresolved externals C:\gtk_compilation\glib\glib-2.46.0\build\win32\vs12\Debug\Win32\bin\gobject-2-vs12.dll gobject
Error 4 error LNK2019: unresolved external symbol ___chkstk_ms referenced in function _ffi_call C:\gtk_compilation\glib\glib-2.46.0\build\win32\vs12\libffi.lib(ffi.o) gobject
I recompiled the libffi using the procedure described here but with
extra flags given to ./configure like below.
cflags="-fno-stack-check -fno-stack-protector -mno-stack-arg-probe"
which i hope will get rid of the ___chkstk_ms invocations.
After make and make install of libffi, I renamed the libffi.a to libffi.lib and libffi.dll.a to libffi.dll and copied them to appropriate directories.
Then I re-build the gobject project in visual studio and I got the same error
which I mentioned in the beginning. :(
Edit:
From this post, I guess the problem's root is that I am using two compilers. But i don't see a way to get around it. I tried to compile
the libffi using Visual Studio Projects available, but hours of efforts
were in vain.
I resolved this using the MSVC build of Libffi found in the Github project.
However, you need to change the line#606 from
sizet z = (*p_arg)->size;
to
unsigned long long z = (*p_arg)->size;
because the typedef is not (for some reason effective here).

Clang+LLVM static library linking error on Windows - Why would the symbols be different?

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.

Boost Linker Error: unresolved external symbol

I built boost latest version (64 bit, msvc-10.0). When using the libraries with my project getting following linker error:
error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?
Things checked:
1. Libraries are present in the path specified
2. Built 64-bit boost library
3. Using latest boost headers, etc..
Any suggestions?
I've experienced the same problem when using some header-only boost library. The problem is some libraries are themselves header-only, but they depend on boost.system which need be linked against your program.

Error LINK2019 using OpenNI and Visual Studio

I am trying to built a .cpp file using OpenNI in Visual Studio 2012. I am using the code of the SimpleViewer sample (it is included in the OpenNI). When I try to build the .cpp file I got the error LNK2019 which it seems a problem when the compiler has to link the OpenNI library. What could be wrong?
Errors (55 in total):
> Error 1 error LNK2019: unresolved external symbol __imp__oniShutdown
> referenced in function "public: static void __cdecl
> openni::OpenNI::shutdown(void)"
> (?shutdown#OpenNI#openni##SAXXZ) C:\Develop\VisualStudioWorkspace\Projects\My
> programs\OpenNI2_test\OpenNI2_test\Viewer.obj OpenNI2_test
Error 2 error LNK2019: unresolved external symbol __imp__oniWaitForAnyStream referenced in function "public: static enum openni::Status __cdecl openni::OpenNI::waitForAnyStream(class openni::VideoStream * *,int,int *,int)" (?waitForAnyStream#OpenNI#openni##SA?AW4Status#2#PAPAVVideoStream#2#HPAHH#Z) C:\Develop\VisualStudioWorkspace\Projects\My programs\OpenNI2_test\OpenNI2_test\Viewer.obj OpenNI2_test
I followed all the steps described in the OpenNI website to compile a file in Visual Studio: I added all the VCC Directories and the Include and Lib environment variables. I also added OpenNI2.lib in the additional dependencies on the Linker section. I also copied the Redist files in the working directory (the directory where I have the .vcproj).
I ran into a similar issue. The sample projects wouldn't build because I was using OpenNI for x64 but the platform was set to Win32. Changing to x64 (in the properties dialog at the top) fixed it for me.
OpenNI 2.0 is not mature enough. Most of the libraries, open source codes, examples and wrappers still use OpenNI 1.5. The integration is not easy since OpenNI2 uses the Microsoft official drivers and OpenNI1.x uses the open source drivers. The 32bit version gives less problems than the 64bits but I ended up installing and working the OpenNI 1.5 and the Kinect non-official drivers.
The problem is related to the linking process. You may have wrong link path in the properties of your projects. There is solution, check this question
maybe it works in your case!

Resources