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.
Related
InstallShield must be the crappiest "industry standard" application in existence, for reasons too numerous to enumerate here. However, one of those deficiencies is something I'd like to be able to fix, and with my first foray into writing an extension for Visual Studio (currently using 2015 version).
InstallShield has created a .isproj type, to allow integration with Visual Studio. This allows a developer to create an installer that references the output of a project as the files to include in the installer (rather than having to manually select individual files to include). This works well enough as long as the .isproj is being built in Visual Studio, and in a solution that references the project for which you need the output.
However, I also have an automated build for my installer projects, that we run on a build server using MSBuild. When attempting to build this way, we were getting completely opaque error messages indicating that the project output references above couldn't be resolved.
As with all InstallShield errors, Googling for answers turned up nothing except for multitudes of other people having the same problem. So I decided to dig into the plain text of the .isproj to see what I could find.
As it turns out, the .isproj type is a just a regular MSBuild script, and it even has lines commented out that explain options that can be added to the project; one of those things that can be added is an ItemGroup containing ProjectReference nodes. Manually adding the nodes helped solve the problem. Command-line build now works.
However, I am dissatisfied with a) having to manually type this stuff in, b) having no visual representation of what projects are being referenced, and c) not finding out about a problem until the build fails. So, I would like to be able to extend Visual Studio to help me with this. Here's what I'd like to do:
1) Add a "References" node to the project in Solution Explorer that acts like the References node for any normal .csproj.
2) Restrict the available References to other projects in the the current solution.
3) Visually represent a project with missing references (e.g. by underlining the project name with a colored squiggly, as with errors/warnings), and potentially failing the build if missing (depending on whether I want to treat it as an error or a warning; TBD).
To these ends, I've downloaded MPF for Projects - Visual Studio 2013, which provides an SDK for creating a new project type.
However, before digging too deeply, I need to know if it's even possible to EXTEND an existing project type, as described above, as I obviously don't have InstallShield source code. Also, any links or guidance as to a starting point for doing so would be greatly appreciated.
YES, I have seen the posts that all you need to do is link it. Find you .lib and link. I have 10 years IT experience and its not at all clear to me where/how the link settings are made. This is a DLL that is not in another project. I have the lib and I have spent hours just trying to find out how to pull this in. Just curious, why there is not some tab saying external libraries, and a browse button to goto whereever you stored this on your file system? I just don't get the multiple steps to get this file linked up. Someone please spell it out. I'm on Visual C++ Express 2010.
Did you try just using "Add Existing File to Project", browsing to the .lib and adding it? Visual Studio recognizes the file type and passes .lib files to the linker.
There's another way which is more complicated and also more powerful. You can open the project properties by right-clicking the project in Solution Explorer. Then go to the Project Directories and add the path to the LIB paths, then go to Linker Input and add the library name (without path) under additional inputs. The advantage of this second method is that you can have different versions of the .lib and .dll for release vs debug, or 32-bit vs 64-bit builds.
In addition to Bens answer, you can also use pragma directives:
#pragma comment ( lib, "path-to-library-file.lib" )
Some prefer linking libraries in the project, others prefer it in the source file. It doesn't make much of a difference either way.
I'm attempting to use the boost library in my C++ project (Visual Studio 2008).
However on including the boost functions for time:
#include <boost/date_time/gregorian/gregorian.hpp>
I get the following error (along with a number of warnings):
fatal error LNK1104: cannot open file 'libboost_date_time-vc90-mt-gd-1_44.lib'
The file 'libboost_date_time-vc90-mt-gd-1_44.lib' is present on my machine and I've used
the boost library before without any difficulties.
Any idea what might be wrong?
The linker cannot find the library file. This could mean that it is not searching in the correct directories. In the properties of the project you should go to the Linker section and make sure that the boost dir is correctly spelled out. Right click on the project, click on Properties -> Configuration properties -> Linker -> Input and you will find "Additional dependencies".
System wide you can go to Tools -> Options -> Projects and solutions -> VC++ Directories, then pick "Library files" in the pull down menu on the right.
If I recall correctly the boost pro installer takes care of this.
Globally: Tools --> Options --> Projects and Solutions --> VC++ Directories "Library files" (as already answered above)
Per project: Project Properties --> Linker --> General --> Additional Library Directories
Did you use any libraries before that required the Boost binary libraries for linkage? Many of the Boost libs are header-only - if you haven't previously used ones that aren't, then that's why you are hitting this now, and the solution is as posted by others - make sure they are present on your build box and set up the build env to reference them.
Is there any way to get Intellisense in Visual C++ for Visual Studio 2005?
I'm trying to get the Boost libraries to load up with intellisense and in the object browser/class view.
I installed the binary for Windows with the BoostPro installer (BoostPro 1.40.0 Installer).
I'm not certain that it comes with the source code however, which may be required to make Intellisense work in VS2005.
Boost is open source, and mostly header only. Just make sure IntelliSense knows the directory where boost resides so it can explore it.
As an un-answer, you might try out Visual Assist X, which works far better and has more features that Visual Studio's IS.
To make sure Intellisense can find boost, just make sure Boost is in the include directories (under Project Properties->C/C++->Additional Include Directories). Maybe move it to the top. After that, close your instance of Visual Studio, and search the a *.ncb file near your project, and delete it. This will cause IntelliSense to refresh. This should hopefully be enough for it to assist you. (You have to include boost headers into your source files with #include for IntelliSense to consider it)
Keep in mind boost has some very complex parts that IS will choke on, but should still provide the names.
Intellisense scans the headers #included in source files in Visual C++ projects.
So create a project with a single source file that includes the top level header of the boost library that you're interested in. Some of the boost code can't be parsed by intellisense though, and the boost code contains a lot of code to workaround language or compiler limitations that's just noise to someone wanting to see the user facing structure of the libraries.
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.