So I'm trying to get the first exercise in the OpenGL Superbible 5th edition to run. It should draw a triangle. I've managed to fix all of my dumb typos. Now I'm down to just two error messages, one of which I think is familiar;
1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
1>LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
I think I stumbled across LNK1123 when I first used C++, and I fixed it by disabling 'Incremental Linking' in the project settings. However, when I try this now, though the program does run and a window does open, no triangle is drawn, and I'm given a list of errors relating to OpenGL tools. And LNK4098 is still there as well.
This is my first project using library imports. Although it was a minefield trying to get it to work, I finally got the graphics libraries GLEW and freeGLUT into my project, by adding them to the project's include path list, and then adding them as existing items to the project. But I suspect that this method has upset the mighty VC++. Could someone please help?
This has nothing to do with OpenGL. This error is basically telling you that you are using the multi-threaded version of Microsoft's C standard library in a project that is already linking to another version of the library.
The interesting thing is that newer versions of MSVC do not have different versions of the C standard library for threaded vs. non-threaded. Thus, your MSVC version is relevant information that is absent from the question.
In any case, the linker warning actually tells you exactly how to resolve the warning. You can add /NODEFAULTLIB:libc to the linker command in your project settings. There is usually an edit-box in the project settings to accomplish this as well, but since its location varies from version to version, adding this to the command-line is simpler.
As for the COFF issue, this is related to the generation of debug symbols in an incremental linking project. /INCREMENTAL:NO should fix this issue. Regarding the cause of it, have you installed different versions of MSVC on this system in the past?
Related
During installation I get "The feature you are trying to use is on a network resource that is unavailable" and prompt to specify some path to vc_runtimeMinimum_x64.msi. After providing some path to required file I get error states that this file doesn't match required version Minimum Runtime 14.14.26405.
I finally found the solution reading this question: Install vcredist_x64 with VS2017 installer project
I realized that specific VC_Redist.x64.exe files could be downloaded by links like https://aka.ms/vs/15/release/26405.00/VC_Redist.x64.exe, where 26405.00 is exactly the version I was required to fix. Note, that you need version from error text after clicking OK, not from window title.
And the last point is that this exe must be executed from cmd with argument /repair to help me with this issue. Regular execution by double click made no effect.
I found the solution elsewhere. It said to
Fix problems that block programs from being installed or removed
https://support.microsoft.com/en-us/help/17588/windows-fix-problems-that-block-programs-being-installed-or-removed
download troubleshooter button on the link.
Run it - choose option - have problem with installing - it lists programs - choose the missing / problematic visual c++ runtimes in the list
it will run and get fixed.
Repeat for each visual c++ you having problems with. I ran the program multiple times.
I have to thank this comment section for helping me with this problem, since I have not been able to work more efficently with my school, since I din't know what and if a single file somewhere deep down in the computer had to be deleted for this program to work.
I am trying to follow this guide
to configure VC++ for WxWidgets. I got stuck here.
So for Core wxWidgets libraries to include, I did include wxmsw31u[d]_core.lib and wxbase31u[d].lib under Linker>>Input>>Additional Depenedencies. That is all to it right?
As for Linking with correct runtime library, can someone tell me how that is done? I manage to get here but don't know how to set the indicated settings.
Please help. I really appreciate it.
When you want to debug your app the debugger must know where in the compiled code is each function used. In jargon, the "debugging symbols". Windows puts these symbols in the compiled executable, while Linux uses another, .devfile.
When you compile code (your app or wxWidgets library) you must tell the compiler whether you want a "Debug" version or a "Release" one.
If you want the debugger to be able to step into wxWidgets code, then you must compile wxWidgets in "debug" mode, which will add the character d to the library files built. So, you must add, for example, wxmsw31ud_core.lib to your app dependencies. Notice the d between u and _. Use the file explorer to see all files generated by wxWidgets compilation process.
Perhaps you don't want all this wxWidgets "debug". Then use another wxWidgets compilation route and add wxmsw31u_core.lib instead of the d'd version. Still you can compile your own app in debug mode, but not being able to step through wxWidgets internals.
Now for your app, a) do you want a single executable file also containing wxWidgets code? or b) let your app in a .exe file which uses as needed external .dll files?
a) is called "static linkage" while b) is called "dynamic linkage"
As you can see, there are four combinations of debug/release & static/dynamic. You must choose one "runtime library" to link to your app.
The table in the wiki shows the switch and MSVC lib (select the desired combination in the 'properties' page) to use in your app; and macro definition required to build wxWidgets if you use nmake instead of the already provided configurations in VS.
Take a look at docs\msw\install.txt for more info.
The best advice I give is that you look into "minimal" sample project. Load it into VS and read every option. You can even make a copy, change some file names and use it for your own app.
I recommend using the official instructions instead of the wiki, they're simpler and, if you look at the last paragraph, you can see that you don't even have to link the libraries manually with MSVC.
You also don't need to do anything special to link with the correct version of the CRT, the defaults are just fine.
I was happily compiling and running source code today. Then I added a few lines to one of my modules, and suddenly Visual Studio 2012 refused to compile the code, with the error message:
error C1083: Cannot open include file: 'rpcerr.h': No such file or directory.
I'm not sure why the compiler suddenly needs to find rpcerr.h. I'm not doing anything I wasn't doing yesterday, but now I can't make the error go away.
I also have not been able to find rpcerr.h, myself. The reference is in rpc.h, which is part of the Visual Studio library. I'm guessing it got linked in because I included <windows.h>. But I don't know where I can find rpcerr.h, or what this file is supposed to do.
I would really like to go forward with this development. I'm guessing the code tried to compile rpcerr.h for a good reason, and that if I'm going to be using rpc.h for whatever reason this gets compiled into my source code, then I should get rpcerr.h as well. But trying to find it is sending me into a mobius loop.
Currently, the compiler is only complaining about rpcerr.h.
I'd better write this up, this is bound to happen again sooner or later. The <rpc.h> SDK file is stone cold old and dates back to the days that Microsoft supported writing code for an Apple Macintosh. It still supports it, there's an #include for rpcerr.h. But that file is no longer supplied, only rpcnterr.h is available.
You need to scan your source, or recently added #includes, for the a #define for MAC or _MAC, the one that Microsoft uses to select a Macintosh target. Using the editor's "Go To Definition" context menu command is the easiest way.
Or use this as a workaround:
#undef MAC
#undef _MAC
#include <rpc.h>
Or change the order of #includes. Beware that these workarounds might have side-effects, depending on how the other definition is used.
Debugging in gdb is not convenient for me so I enjoy the nice debugging interface that code::blocks offers. Now that I have moved my project into an area where those flags are required (the ones in the title, of course), I find that I can't compile on code::blocks anymore :/.
Hi everyone I figured out how to add the -lrt. Since -lrt is passed to the linker and not the compiler you can go to Settings->Compiler and Debugger->linker options then press add and after doing a "locate lrt" I found this cute library "/usr/lib/libaticalrt.so." I added the library in the linker options and now those errors disappeared... Time to try boost!
EDIT: Boost was solved in a similar manner. The library represented by lboost_thread is libboost_thread.so. A locate found it at: "/usr/lib/libboost_thread.so." Adding it in the linker options solved the problem :D
I am getting an error while porting my application from VC6 to Visual Studio 2005.
Does anyone have any idea what this means?
mfcs80.lib(dllmodul.obj) : error
LNK2005: _DllMain#12 already defined
in MSVCRT.lib(dllmain.obj)
From http://support.microsoft.com/default.aspx?scid=kb;en-us;q148652
A LNK2005 error occurs when the CRT
library and MFC libraries are linked
in the wrong order in Visual C++
Because
The CRT libraries use weak external
linkage for the new, delete, and
DllMain functions. The MFC libraries
also contain new, delete, and DllMain
functions. These functions require the
MFC libraries to be linked before the
CRT library is linked.
So
There are two ways to resolve this
problem. The first solution involves
forcing the linker to link the
libraries in the correct order. The
second solution allows you to find the
module that is causing the problem and
to correct it.
Either
Force Linker to Link
Libraries in Correct Order
On the Project menu, click Settings.
In the Settings For view of the Project Settings dialog box, click to
select the project configuration that
is getting the link errors.
On the Link tab, click to select Input in the Category combo box.
In the Ignore libraries box, insert the library names (for example,
Nafxcwd.lib;Libcmtd.lib).
Note The linker command-line equivalent in /NOD:.
In the Object/library modules box, insert the library names. You
must make sure that these are listed
in order and as the first two
libraries in the line (for example,
Nafxcwd.lib Libcmtd.lib).
To set this option in Visual C++ .NET,
read the "Setting Visual C++ Project
Properties" online help topic.
Or
Locate and Correct the
Problem Module To view the current
library link order, follow these
steps:
On the Project menu, click Settings.
In the Settings For view of the Project Settings dialog box, click to
select the project configuration that
is getting the link errors.
On the Link tab, type /verbose:lib in the Project Options
box.
Rebuild your project. The libraries will be listed in the output
window during the linking process.
I'm sure there are a number of reason this could happen - the worst one I ever found was when trying to integrate a number of static libraries (ours) that were originally DLLS (in fact, we build the projects as both DLL & static libraries).
Our C++/CLI DLL was using the static versions of these libraries (To avoid DLL dependency issues that were causing ASP.NET loading issues when the C++/CLI Dll was being used) and was initially seeing the same linker error.
The problem turned out to be the use of AFX_MANAGE_STATE(AfxGetStaticModuleState()) macro that was needed when the code was built as a DLL but not actually needed for the static library call.
To solve this i ended up adding the following code to the stdafx.h of each project.
#ifdef OMUTILITIES_LINK_STATIC
#undef AfxGetStaticModuleState
#define AfxGetStaticModuleState AfxGetModuleState
#endif
This, of course, may not be your specific problem. But the way i eventually figured it was by turning on the /VERBOSE option for the linker and seeing who, what, where & when it was pulling in the runtime libraries. (Project Properties/Configuration Properties/Linker/Show Progress in vs2005)
You could set the linker input to ignore the troubling library in the project properties, but this may or may not work.