I built SpiderMonkey v60 (the Firefox Javascript Engine) release like in the official documentation as a static library (I am trying to avoid dlls). After I added the import files and the js_static.lib to Visual Studio, linking errors occured.
I defined STATIC_JS_API (which should mean that mozilla should compile with the static library), but the only thing happened was the errors got more. I also tried to build SpiderMonkey differently and used mozjs-60.lib to it but nothing changed.
After adding STATIC_JS_API, I had compiling errors like "unresolved extern symbol _imp_timeBeginPeriod#4", "unresolved extern symbol _imp_timeEndPeriod#4", "unresolved symbol _imp_PR_GetOpenFileInfo" (altogether 7 unresolved symbols). I am using the hello world code from mozilla for SpiderMonkey 52, so this should be no problem, also the full building ran off without an error.
Related
I've got a C++ Builder (Rad Studio Berlin) project setup to use Direct2d. Canvas drawing works just fine with the TDirect2DCanvas which would indicate Direct2D is linking properly. Everything renders smoothly. However, I need to use a matrix. I get linking error when I try to. For example, when try I:
canvas->RenderTarget->SetTransform(D2D1::Matrix3x2F::Rotation(15.0, D2D1PointF(100, 100)));
...I get the following linking error:
[ilink32 Error] Error: Unresolved external 'D2D1MakeRotateMatrix' referenced from C:\DP\TRUNK\SRC\CLIENTSIDE\APPLICATIONS\VIEWER\WIN32\DEBUG\MIMAGE.OBJ
C++ builder was supposed to already be setup to link against direct2d if I just include the headers. Can anyone help me link against the appropriate files in the C++ Builder way?
I found the solution from a different source. Here it is:
After some research, this issue has not been determined to be a bug.
For many of the standard Windows API functions, the IDE will add the correct library automatically so that the dependencies on the function references will be satisfied. With DirectX (which is somewhat uncommonly used), the IDE does not automatically supply the library which corresponds to the header file, so this is causing the unresolved linker errors.
The solution is to either (as I mentioned previously) add the D2D1.lib to the project, or statically reference it in code:
// as long as D2D1.lib is on the library search path, it should be found
#pragma comment(lib,"D2D1.lib")
Some developers add the above line of code to their headers and so all you need to do is include the header and all is well... the DirectX team did not do this and hence the unresolved linker errors.
Hope this clarifies the issue,
The compile all goes well. However, when it goes to the link stage, error comes out:
error LNK2001: unresolved external symbol _ptrc_glClear
There're also many other errors with the same link error, including _ptr_glViewport, _ptr_glDrawArrays......
I'm searched in stackoverflow, and find many questions about the link problem of opengl32.lib. I followed their advice, but still it doesn't work.
I also notice that, the problems occurred in others' question(error LNK2019: unresolved external symbol), appear to be somewhat different: what they failed to link is with the prefix "imp", while mine is "ptr".
I wonder, is the problem of the "_ptrc_xxxxx" thing also comes with the opengl32.lib, or did I miss some other libs to link?
Are you using any kind of OpenGL loader library (GLee, GLEW, glLoadGen)? Prefixed OpenGL symbols are usually imposed on your source code by including such a loaders header (which uses some preprocessor magic to turn all OpenGL symbols in your code into symbols referring to the loader). If then your program fails to link with that very loader you'll get these unresolved symbol linker errors.
I get the following error while trying to build a CUDA/C++ code in Visual Studio 2012. I'm using CUDA v5.0
1> Generating Code...
1>LINK : warning LNK4044: unrecognized option '/MLd'; ignored
1>cublas_device.lib(kepler_sm35_gemm_wrapper.obj) : error LNK2019: unresolved external symbol __cudaRegisterLinkedBinary_59_tmpxft_00001040_00000000_8_kepler_sm35_gemm_wrapper_cpp1_ii_9402ff4f referenced in function "void __cdecl __sti____cudaRegisterAll_59_tmpxft_00001040_00000000_8_kepler_sm35_gemm_wrapper_cpp1_ii_9402ff4f(void)" (?__sti____cudaRegisterAll_59_tmpxft_00001040_00000000_8_kepler_sm35_gemm_wrapper_cpp1_ii_9402ff4f##YAXXZ)
Anybody has any idea of where the problem might be? I've tried googling around, but haven't found a solution for this as yet.
Thanks a lot!
This article shows information about what the /MLd linker option does. It essentially has to do with multithreaded libs being loaded and the configuration of your project.
Is your (Debug) project set up to link with the microsoft linker or nvcc? (The error messages appear to be coming from the microsoft linker.) You may want to look at this question
Device code and device libraries (that you are linking against) need to be linked with nvcc.
You need to link against the debug version of the CUDA library. You try to compile in Debug mode, but then you link against a library which seems not to have been built in debug mode. Thus it gets all messed up.
So you should either get the .lib file for the debug version, or build it yourself if you have the source code. Then you link your debug build with the debug .lib and same for release.
Also, it may help that you use the same version of the compiler to build all libs, otherwise you may run into name mangling issues (which could be also a potential cause for your problem). It happened to me after switching to a newer VS version: I had to recompile all the .lib I was linking against.
It looks like some sort of using a external (extern) variable that isn't defined. The code is required for further information
I was able to fix it! I was linking to cublas_device.lib which was referring to an unresolved external symbol. However, this lib file wasn't required by my project, so just removing it from the linked files worked! However, in Release mode this error wasn't happening - maybe because this part of the code in cublas_device.lib was in the debug section.
In any case, since it is not required by my project, removing it solves the problem.
Thanks a lot for all your replies!
I encountered the same issue, Changing the Configuration Type from "Dynamic library (dll)" to "Static library (lib)" worked for me.
I'm trying to get around these link errors:
error LNK2001: unresolved external symbol "__declspec(dllimport) public void __thiscall std::basic_ostream(char,struc std::char_traits<char>>::_0sfx(void)"
I used Visual Studio C++ 2010, and tried with Visual Studio C++ 6.0, but still the same errors show up.
The object file is found, so I am suspecting that it cannot find the implementation of the std library? I've tried /nodefaultlib option on a few libraries (libc.lib, libcmt.lib, msvcrt.lib, etc) but did not improve the situation at all.
Could someone explain why the error occurs and where I should look ?
Tried the solutions suggested in other similar questions but they either are not applicable or do not resolve the problem.
Thanks
You should remove /nodefaultlib option.
This problem could arise if some of your libraries are linked static while other dynamically.
Basically if you have both codes compiled with the static version of CRT (that's compiler switch /MT and /MTd) and dynamic version of CRT (switch /MD, /MDd).
You can see what your project is using in Project Properies - c++ - Code Generaion - Runtime Library)
Make sure all your libraries are compiled with the same switch as you project.
I have a question about how constants defined in math.h are linked.
In visual studio 2010, I'm building a 64-bit dll c++ library with "MD" that uses a third party library that make use of "HUGE_VAL". From the header "math.h", it seems that "HUGE_VAL" is defined as "_HUGE". When I try to build, a linking error results
error LNK2001: unresolved external symbol _HUGE
After doing some googling, I think _HUGE should be defined in msvcrt.lib. MSVCRT.lib is linked, but I didn't link libcmt.lib because it would cause re-definition errors.
What strikes me as odd is that when I create a simple console program that uses HUGE_VAL and use /verbose as a linker option, it shows _IMP_HUGE being linked.
What I'm really curious of is at what stage does _HUGE turn into _IMP_HUGE? Also, have anyone else gotten the unresolved _HUGE error and does anyone have any ideas for how it could be fixed?
Thanks for reading the long question and for any ideas.
I have experienced this issue with VC11.0. The only error I get is an unresolved symbol _HUGE error.
I am linking with dynamic multi-threaded run time libraries and I found that if I were to include "libcmt.lib" in my link step, then the issue is resolved (or worked around).
I started looking into how the headers were defined in the SDK for clues and found that I was missing a compiler pre-directory in my compile steps: _DLL.
When you build with dynamic run time libraries the _HUGE variable needs to be __declspec(dllimport) so it can be found. When you include "math.h" -> "crtdefs.h" without setting _DLL as a pre-directive, the variable will not be __declspec(dllimport)'ed and will appear missing at link time.
I was getting this issue because I am compiling with my own custom makefiles and I had neglected to add the _DLL pre-directive. Adding -D_DLL to my compilation step resolved the compile issue with no other changes needed.
I know this thread is old, but figured I would throw it out there as it may help someone with a similar issue.