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
Related
There are two projects, in one case of an error I saw 'clang++', in the other I saw nothing. Android.mk and Application.mk almost identical, the compilers are not listed anywhere in these files. I read somewhere that GCC is used by default, but I began to doubt something.
Which NDK compiler is used by default? And which is better GCC or Clang ?
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.
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?
I am makeing a small mod to SMPlayer; the Linux version...
The make, sudo make install from the command line works, but I would like to have the project in an IDE.
I want to use CodeBlocks IDE, only because I've used it before, but if some other IDE is required, I can use that instead... (I use Codeblocks because it is simple, and that suits my current ability to handle an IDE)..
Is there some way to use SMPlayer's Makefile, or some such thing?
This depends on the IDE and has little to nothing to do with Linux.
Does your program come with something like cmake or another setup tool? That normally makes it much easier. For example in KDevelop you can import straight from CMakeLists.txt and Makefiles.
If all else fails it might be quite easy to do something like this (not knowing your specific IDE):
Add new Project
Set build directory and other necessary settings (like compiler and compiler flags)
Add the already existing files to it.
Press "Compile"-button.
This is obviously depending on the project structure, setup and size.
Code::Blocks has builtin support for Makefile projects. See the FAQ.
Also you could just use vim or emacs ;)
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.