Build wxWidgets 3.1.3 with VS2019 Topic is solved

Do you have a question about makefiles, a compiler or IDE you are using and need to know how to set it up for wxWidgets or why it doesn't compile but other IDE's do ? Post your questions here.
Post Reply
Natulux
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 223
Joined: Thu Aug 03, 2017 12:20 pm

Build wxWidgets 3.1.3 with VS2019

Post by Natulux » Mon Mar 09, 2020 3:00 pm

Hey,
I built several wxWidget versions with several Visual Studio versions on Windows10 now, but to be honest: I had the privilege of using the project files that come with wxWidgets for vs users.
Now I run into a problem compiling wxSqlite 4.4.6 (from utelle) with wxWidgets 3.1.3 MD:

The wx/setup.h is included and in the wx/setup.h, this is included:

Code: Select all

#include wxSETUPH_PATH_STR
Which resolves to:

Code: Select all

wxCONCAT6(../../../lib/, wxLIB_SUBDIR, /, wxTOOLKIT_PREFIX, wxSUFFIX, /wx/setup.h)
//with:
//wxLIB_SUBDIR = wxCONCAT4(wxCOMPILER_PREFIX, wxARCH_SUFFIX, _lib, wxCFG)
//with:
//wxCOMPILER_PREFIX = vc
//AND
//wxARCH_SUFFIX = "" (empty)
This was fine for all versions before this, but suddenly (because of studio and/or wxW) the wxWidgets library now is under
C:\wxWidgets-3.1.3_MD\lib\vc142_lib
So the Arch_Suffix should have been "142", but it is not set in the setup.h and thus the include, mentioned earlier, can't be resolved.

I think I heard that I could set this var when building the setup files myself, but I don't know the details here.

I am using wxW 3.1.3 Win32 Release MultiThreaded-DLL build for Windows10x86 with VS2019Community.
Any hint for cmake or another way for windows users to either undef Arch_Suffix for wxW build or to define it for the setup.h?

Thanks!
Natu

stahta01
Super wx Problem Solver
Super wx Problem Solver
Posts: 365
Joined: Fri Nov 03, 2006 2:00 pm

Re: Build wxWidgets 3.1.3 with VS2019

Post by stahta01 » Mon Mar 09, 2020 7:17 pm

I would guess that wxCOMPILER_PREFIX is vc142 .

wxARCH_SUFFIX is normally x64

EDIT2: You really should post the command you used to build wxWidgets!

Tim S.

ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 4170
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: Build wxWidgets 3.1.3 with VS2019

Post by ONEEYEMAN » Mon Mar 09, 2020 9:14 pm

Hi,
Are you building using "CMake"? Or directly with MSVC?

Thank you.

utelle
Moderator
Moderator
Posts: 940
Joined: Tue Jul 05, 2005 10:00 pm
Location: Cologne, Germany
Contact:

Re: Build wxWidgets 3.1.3 with VS2019

Post by utelle » Mon Mar 09, 2020 9:27 pm

Natulux wrote:
Mon Mar 09, 2020 3:00 pm
I built several wxWidget versions with several Visual Studio versions on Windows10 now, but to be honest: I had the privilege of using the project files that come with wxWidgets for vs users.
Now I run into a problem compiling wxSqlite 4.4.6 (from utelle) with wxWidgets 3.1.3 MD:
The build files for Visual Studio coming with wxSQLite3 use a property file (wx_setup.props) for configuring certain environment settings (like the compiler prefix). Since the Continuous Integration test are based on a precompiled wxWidgets version in which the Visual Studio version number is included in the compiler prefix, the property file is configured accordingly. For your environment you will have to adjust the file wx_setup.props in the build directory, so that the values for compiler prefix and automatic Visual Studio version look like the following:

Code: Select all

<wxCompilerPrefix>vc</wxCompilerPrefix>
<wxMsvcVersionAuto></wxMsvcVersionAuto>
BTW, this is explained in a small note under the wxSQLite3 4.4.6 release.
Natulux wrote:
Mon Mar 09, 2020 3:00 pm
The wx/setup.h is included and in the wx/setup.h, this is included:
This was fine for all versions before this, but suddenly (because of studio and/or wxW) the wxWidgets library now is under
C:\wxWidgets-3.1.3_MD\lib\vc142_lib
So the Arch_Suffix should have been "142", but it is not set in the setup.h and thus the include, mentioned earlier, can't be resolved.
If you built wxWidgets using one of the Visual Studio solution files coming with wxWidgets, the compiler prefix vc is used without any Visual Studio version number. To force the wxSQLite3 build files to use the very same compiler prefix, you have to adjust wxSQLite3's wx_setup.props file as described above.

I hope this information helps you to sort things out.

Natulux
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 223
Joined: Thu Aug 03, 2017 12:20 pm

Re: Build wxWidgets 3.1.3 with VS2019

Post by Natulux » Tue Mar 10, 2020 8:01 am

stahta01 wrote:
Mon Mar 09, 2020 7:17 pm
I would guess that wxCOMPILER_PREFIX is vc142 .

wxARCH_SUFFIX is normally x64
You are right, my mistake.
ONEEYEMAN wrote:
Mon Mar 09, 2020 9:14 pm
Are you building using "CMake"? Or directly with MSVC?
MSVC! I was just considering cmake because I wasn't aware I could configure wxWidget build via setup files even after the cmake project file build.

utelle wrote:
Mon Mar 09, 2020 9:27 pm
The build files for Visual Studio coming with wxSQLite3 use a property file (wx_setup.props) for configuring certain environment settings (like the compiler prefix). Since the Continuous Integration test are based on a precompiled wxWidgets version in which the Visual Studio version number is included in the compiler prefix, the property file is configured accordingly. For your environment you will have to adjust the file wx_setup.props in the build directory, so that the values for compiler prefix and automatic Visual Studio version look like the following:

Code: Select all

<wxCompilerPrefix>vc</wxCompilerPrefix>
<wxMsvcVersionAuto></wxMsvcVersionAuto>
BTW, this is explained in a small note under the wxSQLite3 4.4.6 release.
Thanks for pointing me directly to it, Ulrich! It seems like I now have to decide if I want to have that version number. Rather not, I guess.
utelle wrote:
Mon Mar 09, 2020 9:27 pm
If you built wxWidgets using one of the Visual Studio solution files coming with wxWidgets, the compiler prefix vc is used without any Visual Studio version number.
Thing is, in my case wxWidgets does build with vc142, so wxMSVC_VERSION or wxMSVC_VERSION_AUTO has to be defined somewhere prior to this. But maybe I messed with these project files last year. I guess I better start off using files from a new download.
utelle wrote:
Mon Mar 09, 2020 9:27 pm
To force the wxSQLite3 build files to use the very same compiler prefix, you have to adjust wxSQLite3's wx_setup.props file as described above.

I hope this information helps you to sort things out.
Yes, this helps a lot! Now that I know where to push and pull, I'll manage. Thanks a bunch!

Cheers
Natu

Natulux
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 223
Joined: Thu Aug 03, 2017 12:20 pm

Re: Build wxWidgets 3.1.3 with VS2019

Post by Natulux » Tue Mar 10, 2020 8:40 am

A fresh download of wxW313 and wxS451 together with your configuration advise worked like a charm!

The only thing I couldn't properly set in the setup props was the distinction between static and shared libraries, because unfortunately I need both.
I used to having them in seperate directories, I'll try to just rename the lib dir now (vc_lib_MD and vc_lib_MT).
If that works thats good enough for me. ;-)

[EDIT:] I decided it is better and safer to use the built in ways for that naming process. I just modified the setup props to
<wxCompilerPrefix>vc_MD</wxCompilerPrefix>
and
<wxCompilerPrefix>vc_MT</wxCompilerPrefix>
for wxWidgets and wxSqlite each before compiling first wxW and then wxS.
And here is the first downside doing that:
Compiling the wxWidgets minimal sample uses wxOutDirName for the lib name, which is defined in the global wx_setup.props. So first I need to omit that variable and provide a fixed path. I hope there is not much more like this coming..

All the best
Natu

utelle
Moderator
Moderator
Posts: 940
Joined: Tue Jul 05, 2005 10:00 pm
Location: Cologne, Germany
Contact:

Re: Build wxWidgets 3.1.3 with VS2019

Post by utelle » Tue Mar 10, 2020 12:25 pm

Natulux wrote:
Tue Mar 10, 2020 8:40 am
A fresh download of wxW313 and wxS451 together with your configuration advise worked like a charm!
Good to hear.
Natulux wrote:
Tue Mar 10, 2020 8:40 am
The only thing I couldn't properly set in the setup props was the distinction between static and shared libraries, because unfortunately I need both.
I used to having them in seperate directories, I'll try to just rename the lib dir now (vc_lib_MD and vc_lib_MT).
If that works thats good enough for me. ;-)
As far as I know the Visual Studio solution files of wxWidgets do not support to select the static C runtime libraries. One has to modify them manually, or has to use the makefile.

The wxSQLite3 Visual Studio solution files also do not support to select the static C runtime libraries. However, you could regenerate them with premake5, after adjusting the file premake5.lua.
Natulux wrote:
Tue Mar 10, 2020 8:40 am
[EDIT:] I decided it is better and safer to use the built in ways for that naming process. I just modified the setup props to
<wxCompilerPrefix>vc_MD</wxCompilerPrefix>
and
<wxCompilerPrefix>vc_MT</wxCompilerPrefix>
for wxWidgets and wxSqlite each before compiling first wxW and then wxS.
Yes, this should usually be the route to go for building specialized versions of the libraries.
Natulux wrote:
Tue Mar 10, 2020 8:40 am
And here is the first downside doing that:
Compiling the wxWidgets minimal sample uses wxOutDirName for the lib name, which is defined in the global wx_setup.props. So first I need to omit that variable and provide a fixed path. I hope there is not much more like this coming..
Not sure, I fully understand the problem. In principle, it should be correct that the samples use the same settings as the library itself.

Instead of manipulating the file wx_setup.props, you could use wx_local.props to temporarily overwrite settings in wx_setup.props.

Natulux
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 223
Joined: Thu Aug 03, 2017 12:20 pm

Re: Build wxWidgets 3.1.3 with VS2019

Post by Natulux » Tue Mar 10, 2020 12:47 pm

utelle wrote:
Tue Mar 10, 2020 12:25 pm
As far as I know the Visual Studio solution files of wxWidgets do not support to select the static C runtime libraries. One has to modify them manually, or has to use the makefile.
It worked for me in the past and as far as I can see it also works now to select all the projects that come with wxWidgets in Visual Studio, and change them over the IDE with project settings > C/C++ > Runtime Library > Multithreaded (/MT) // or Multithreaded-DLL (/MD) respectively

If I do the same for wxSqlite it is build static (or dynamic respectively) without further complains.
utelle wrote:
Tue Mar 10, 2020 12:25 pm
Natulux wrote:
Tue Mar 10, 2020 8:40 am
And here is the first downside doing that:
Compiling the wxWidgets minimal sample uses wxOutDirName for the lib name, which is defined in the global wx_setup.props. So first I need to omit that variable and provide a fixed path. I hope there is not much more like this coming..
Not sure, I fully understand the problem. In principle, it should be correct that the samples use the same settings as the library itself.

Instead of manipulating the file wx_setup.props, you could use wx_local.props to temporarily overwrite settings in wx_setup.props.
My problem is, that I wanted to have static and dynamic libraries all in one wxWidgets (and all in one wxSqlite) folder.
libs/vc_MT_lib/
libs/vd_MD_lib/
right nex to each other. If I have two wxWidgets "installations", one beeing static, the other one beeing dynamic, there is no problem, because each installation has its own setup.props.
Upon start of my project in visual studio the global variable wxOutDirName is filled with the entry of the global setup.props and that can be either vc_MT_lib or vc_MD_lib.

But don't you worry, I don't have to use wxOutDirName and as of now, that was the only problem with having static and dynamic in one installation.

Cheers
Natu

Natulux
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 223
Joined: Thu Aug 03, 2017 12:20 pm

Re: Build wxWidgets 3.1.3 with VS2019

Post by Natulux » Tue Mar 10, 2020 2:31 pm

One final conclusion:

[EDIT:] I am talking about the used microsoft static/dynamic runtime beeing used from visual studio on windows. Not to be confused with static or DLL build of wxWidgets.

Never try to get static/dynamic compilations of wxWidgets in one directory - weird errors may occur - seperate the whole thing.
What finally works for me:

C:/wxWidgets-3.1.3_MD_2019/ (dynamic debug and release)
C:/wxWidgets-3.1.3_MT_2019/ (static debug and release)

C:/wxSqlite3-4.5.1_MD_2019/ (dynamic debug and release)
C:/wxSqlite3-4.5.1_MT_2019/ (static debug and release)

It needs more disc space that way, but it works.

Post Reply