Tuesday, August 14, 2012

How to use 2.9.4 wxMSW binaries

We have decided to experiment with providing binaries for wxWidgets releases. So, for the first time ever, 2.9.4 release includes binaries for a few different versions of Microsoft Visual C++ compiler.
However we might not have done a very good job of explaining how to actually use them, the README at the link above is relatively brief and omits some steps, so let me try to explain in more details how to build your wxWidgets applications using the files provided and without building wxWidgets yourself.
First, you need to get the correct files. You will always need the headers one but the rest depends on your compiler version and architecture: as different versions of MSVC compiler are not binary compatible, you should select the files with the correct vc80, vc90 or vc100 suffix depending on whether you use Visual Studio 2005, 2008 or 2010 respectively. You also need to decide whether you use the x64 files for 64-bit development or the ones without this suffix for the still more common 32-bit builds. After determining the combination of suffixes you need, you should download the "Dev" and the "ReleaseDLL" files in addition to the "Headers" one above, e.g. for 32-bit MSVS 2010 development you need wxMSW-2.9.4_vc100_Dev.7z and wxMSW-2.9.4_vc100_ReleaseDLL.7z.

Once you have the files you need, unzip all of them into the same directory, for example c:\wx\2.9.4. You should have only include and lib subdirectories under it, nothing else. To avoid hard-coding this path into your projects, define wxwin environment variable containing it: although it's a little known fact, all versions of MSVC support environment variable expansion in the C++ projects (but not, unfortunately, in the solution files).
Next step is to set up your project to use these files. You need to do the following:
  • In the compiler options, i.e. "C/C++" properties:
    • Add $(wxwin)/include/msvc;$(wxwin)/include to the "Additional Include Directories". Notice that the order is important here, putting the MSVC-specific directory first ensures that you use wx/setup.h automatically linking in wxWidgets libraries.
    • Add WXUSINGDLL and wxMSVC_VERSION_AUTO to the list of defined symbols in "Preprocessor Definitions". The first should be self-explanatory (we only provide DLLs, not static libraries) while the second one is necessary to use the libraries from e.g. lib\vc100_dll directory and not the default lib\vc_dll.
    • Also check that _UNICODE and UNICODE symbols are defined in the same "Preprocessor Definitions" section. This should already be the case for the newly created projects but it might be necessary to add them if you're upgrading an existing one.
      [added at 2013-02-08 in response to comments]
    • Check that you use "Multi-threaded [Debug] DLL" in the "Run-time library" option under "Code Generation" to ensure that your build uses the same CRT version as our binaries.
  • In the linker options you only need to add $(wxwin)\lib\vc100_dll (with the compiler-version-dependent suffix, of course) to "Additional Library Directories" under "Linker\General" in the options. Thanks to the use of MSVC-specific setup.h you don't need to list wxWidgets libraries manually, i.e. you do not need to put anything in the list of "Additional Dependencies".

Now you should be able to build your project successfully, both in "Debug" and "Release" configurations. With MSVC 10 it can also be done from the command line using msbuild.exe. Of course, to run the generated executable you will need to either add the directory containing wxWidgets DLLs to your PATH or copy the DLL files to a directory already on it. Finally, if you want to distribute the binaries created using these options, you will need to install Microsoft Visual C++ run-time DLLs. Again, MSVC 10 has an advantage here as you can simply copy msvcp100.dll and msvcr100.dll as any other DLL, while you need to install specially for the previous compiler versions that use WinSxS ("side-by-side") for them.
Let us know if you run into any problems using these binaries or, on the contrary, if you didn't but were glad to have them. If enough people find them useful, we'll try to provide them again for 2.9.5 and, most importantly, for 3.0.


Updated on 2012-08-23T12:55:10: Corrected linker options instructions.

34 comments:

Unknown said...

I found the windows binaries very convenient, thanks and keep them coming if you can.

snowman said...

It would be great if you could add a link to this blog post to wxWidgets Downloads page.

Kechristodoulos said...

Thank you for this post. It is really helpful. I did all the setup as described...but I get a linker error: LINK : fatal error LNK1104: cannot open file 'C:\wxWidgets\lib\vc100_dll.obj. Please help!

VZ said...

@snowman: Good idea, thanks, added.

@Kechristodoulos: "vc100_dll.obj" doesn't exist, you need to link with "vc100_dll.lib".

Kechristodoulos said...

There is no "vc100_dll.lib" neither. vc100_dll is a folder...isn't it? I also tried "C:wxWidgets\lib\vc100_dll*" but it can't load "wxbase29ud.lib"

VZ said...

Yes, sorry, don't know what I was thinking in the previous reply. You don't need to link with anything actually, all the required libraries are linked in automatically with MSVC. I really don't know where does "vc100_dll.obj" come from but just remove it from your project.

And if you need more help, please post to the mailing list, this is really not the best place to discuss.

KOLANICH said...

Enable SSE2 when building.
Also i think it will be good to store dll, pdg and lib files separatly.

VZ said...

@KOLANICH: Not sure if arch options would make any difference, there is precious little code in wx that would benefit from them AFAICS, did you observe any significant differences when enabling them? What options did you use exactly if so?

As for DLL, PDB and LIBs we already provide different files containing them, we only group all the libraries together.

KOLANICH said...

Haven't compared the perfomance, but also haven't seen a modern computer with x86 compatible cpu without SSE2.
SSE2 should make benefits, so why not to use it?

Also I dislike storing header files in lib directory.
Include directory is for headers, lib - for libs.

Shenghi said...
This comment has been removed by the author.
Shenghi said...
This comment has been removed by the author.
Pixelclown said...

It was the first time that I tried to use wxWidgets. I tried to build wxWidgets 2.9.4 with Visual Studio 2010 Express and it failed. It was painfull and a very bad first impression. I would have turned down wxWidgets if there would not have been this prebuild binaries.
After following the installation instructions in this blog post everything worked as expected. It was just neccessary to reboot Windows after defining the environment variable so that Visual Studio could find the headers. I'm now happily exploring what wxWidgets has to offer. So thank you for preparing the binaries!

Unknown said...

help me! When I have used 2.9.4 wxMSW binaries, I can not include "mondrian.xmp". Please, help me include it. Thank you!

VZ said...

Chau, "mondrian.xpm" is not really part of wxWidgets, it's just an icon used in the sample.

But please notice that this is not a support forum. Please use the mailing list or the user forum for the questions, it would be really inconvenient to answer them here.

Unknown said...

It seems _UNICODE and UNICODE need to be added to the list of defined symbols in "Preprocessor Definitions" for linking. As only unicoded version of libraries included into package.

Alexey Kudryavtsev said...

Thank you very much! It seems all working fine and binaries are very useful.

Unknown said...

Thanks, it would be very nice if you keep binaries available in future releases.

Bret said...

I found the binaries to be very helpful. Historically the code I'm working on has used static linking, so having a static copy would be nice, but with binaries available from you, it might be time to switch to dynamic linking.

It did take some reading/digging/looking at truncated columns to figure out exactly what I needed to download. It would have been impossible without this blog post, but perhaps a bit deeper directory structure would make them easier to use.

Something like:


end-users/
win32/
vc100/
dlls.zip
developers/
win32/
vc100/
bundle1.zip
bundle2.zip
...

That way a person could download everything in a single directory and know you had a matched set of what you needed. It would mean having redundant files in some places (like the headers will appear in all the developer directories), but disk space is cheap :-)

Anonymous said...

Will there be any builds for MSVC11 (2012)?

VZ said...

@Bret, disk space in the amounts required is not that cheap. I'd like to find a better organization of the files but it definitely shouldn't involve duplicating them.

@di-0xide, perhaps VC11 could replace VC8. I think providing 4 sets of binaries would be perhaps too much.

projimdy said...

Where I set "Preprocessor Definitions"?

Federico Zamperini said...

I'm surely glad you made the binaries available; I'd like to have them compiled linking against winddk msvcrt.lib, though. This way I could use them to build GUI based gstreamer apps.

Joseph W. said...

Vadim - thank you so much for this blog post. I was able to build the wxWidgets 'Hello World' example from the tutorials in VC++ 2010 Express under Windows 7.

Valeri's point about the UNICODE variables is correct - I had to define those variables too.

If you could, could you update the original blog post to mention this? It may not be obvious to everyone that 'u' means unicode in this case.

Thanks again. Now I can get on with building my cross-platform app instead of fighting with frameworks.

MUCH appreciated!

KariK said...

I gave up trying to build wxWidgets and was happy to find the binaries, and this blog post. Now I get much further in building my project (pgAdminIII for PostgreSQL) but still get this error when linking: cannot open file 'wxbase28u.lib'. Really stuck with this and would greatly appreciate any advice!

VZ said...

@Joseph W.: updated, notice that the Unicode symbols should be already predefined for new projects normally. But perhaps you're updating an existing one?

@KariK: this is really not the right place to look for support, I'd try on pgAdmin mailing list instead. But clearly you need to update it to link with wx 2.9 if you're using these binaries and not 2.8 that it is looking for.

Michael said...

There should be no space in the path of wxwin and restart the vs.net it is running when you are setting the wxwin path.

ChronoCross said...

Hi, I followed up your tutorial
and its work for me, thanks

But the program require wxbase294ud_vc100.dll and wxmsw294ud_core_vc100.dll in program directory

Is there any way to make program running even that 2 libraries isn't in program directory?

Thanks

VZ said...

@ChronoCross, they're just normal DLLs, i.e. they need to be found somewhere in the path, not necessarily in the program directory, but putting them in the same directory as the program is the simplest way if you don't intend to reuse them among several projects.

If you want to avoid using DLLs, then you need to build wxWidgets as static libraries but this is something you must do yourself (this is not difficult at all) as we only provide the binaries for the DLLs.

StiltFox said...

Thank-you very much for the instructions. I am able to do a VS 2010 debug build, but get the error "The program can't start because wxbase294ud_vc100.dll is missing from your computer. The file is here C:\wx\2.9.4\lib\vc100_dll\wxbase294ud_vc100.dll and my path has ;C:\wx\2.9.4\lib\vc100_dll\. Just trying minimal on windows 7. Any ideas what I am missing?

VZ said...

You need to have VC run-time CRT DLLs installed too (they can be downloaded from Microsoft site).

As usual, Dependency Walker can be very useful for debugging DLL-related problems.

krazzyyguy said...

Everything works well. But when i run the program using VS2010 a pop-up occurs saying "wxmsw294ud_core_vc100.dll" and "wxbase294ud_vc100.dll" missing, the program cannot run . I did a workaround by copying them in the same folder the application is. But i dont want to do this everytime. Is there any efficient way of doing this??

Note: I have also added C:/wx/2.9.4/lib/vc100_dll in environment variable PATH. Still no success.

Please help :(

JohnA said...

Thank you for providing the wxWidgets binaries. I am using using them and all is well except for one issue:

I am using the 2.9.4 binaries for Visual Studio 2010 (64 bit). I am not able to step into wxWidgets source when debugging. The debugger is finding my PDBs OK, but complains that there is a checksum mismatch with the widgets 2.9.4 source code which I have also downloaded.

Do I need to build my own wxWidgets in order to step into widgets source code, or have I set something up incorrectly?

Thanks for your help.

Unknown said...

Beautiful! Thanks for this. Way simpler than trying to build and convert a bunch of projects. Thanks again.

ScratchWood said...

Just to mention, I had created a project with the 2.9.5 binaries and DialogBlocks and imported the project into VS2012. No way to get it working that way, even after trying to adapt the settings as described above. I fixed it by creating a new project, copying the code into that project and do the settings as above. And it should be a Windows sub system for the linker. Now it works.