Can't compile with Visual Studio 2022 using .lib Topic is solved

[SteveStage]

I changed build.cfd (runtime libraries dynamic to static), change \MD to \MT, remove WXUSINGDLL preprocessor definition and I don't know how to build my project without .dll dependencies.
Visual Studio 2022 and wxWidgets 3.2.0.
Errors when building:

[doublemax]

What's the beginning of the story?

Did you already have a project that uses wxWidgets and want to switch to static linking instead of dynamic?
Or did you just change wxWidgets version or compiler?

[SteveStage]

Here's my settings, build.cfg and folder with .lib files:
https://imgur.com/a/X8KHW3y
I have VS project with wxWidgets connected.

[doublemax]

That's not what i wanted to know.

Let's start from the beginning: Can you build the wxWidgets library and the "minimal" sample from source?

[SteveStage]

If I write preprocessor definition WXUSINGDLL and build it - everything will work, but built .exe application would be dependent by .dll libraries.
According to this part of code - I don't need WXUSINGDLL definition:

[doublemax]

I'm not a mind-reader, without sufficient information i can't help you.

Maybe this helps:
viewtopic.php?p=196105#p196105

[SteveStage]

I tried to compile Release static libs (by sources and wx_vc17.sln project), but when I use them - I get another errors (looks like 'RuntimeLibrary' in the libraries is MD_DynamicRelease instead of MT_StaticRelease):

[doublemax]

The C runtime settings of your application must be the same that was used when building the libraries. The wxWidgets libraries all default to dynamic linking of the CRT. But your app is set to use static linking. You have to change one of them.

[SteveStage]

My config:
https://imgur.com/a/JXfWkMU
What I am doing wrong? How to compile static-linking libraries by VS project from sources?

[RLWA32]

A simple way that I have used to build the 3.2.0 libs without making any changes to the projects or configuration files as distributed -

1) Open a VS2022 developer command prompt.
2) Navigate to %WXWIN%\build\msw
3) Enter the following to create an environment variable that will override the runtime library settings in the various projects -- set _CL_=/MTd
4) Build the Debug configurations from the command line using msbuild. For example -
msbuild -m:4 -t:build -p:Configuration=Debug;Platform=Win32 wx_vc17.sln
msbuild -m:4 -t:build -p:Configuration=Debug;Platform=x64 wx_vc17.sln
5) Change the environment variable for release builds -- set _CL_=/MT
6) Build the Release configurations with msbuild --
msbuild -m:4 -t:build -p:Configuration=Release;Platform=Win32 wx_vc17.sln
msbuild -m:4 -t:build -p:Configuration=Release;Platform=x64 wx_vc17.sln

The above builds will complete without errors but will generate numerous warnings about overriding /MDd for debug and /MD for release but that's exactly what you want

[doublemax]

How to compile static-linking libraries by VS project from sources?

Download the source package, open the correct solution file from <wxdir>/build/msw/, e.g. wx_vc16.sln.

- select the configuration "debug" and build.
- select the configuration "release" and build.

That's all there is to it.

Addition:
If you want to link the CRTs statically, too:
After loading the solution file, select all projects (from "adv" to "xrc"), ricght-click -> Properties -> C/C++ -> Code Generation -> Runtime Library:
For "debug" config select "Multi-Threaded debug".
For "release" config select "Multi Threaded"

[SteveStage]

I solved it - just set \MT instead of \MD in every project of solution (core, base, html etc).

I though every configuration (Debug DLL or Release) has its own props and set it when I change it, but I was wrong.

[ONEEYEMAN]

Hi,
Keep in mind that if for some reason you MSVC Runtime will conflict with the person who installs the software yo are providing - you might get a crash.

That's why it is STRONGLY advisable to keep C/C++ Run-Time library dynamically linked and only link wx statically.

Let's say you have build you software with MSVC 2010. You link everything statically.
Imagine the situation where the user of your program have MSVC 2022 or has some software that is using Run-Time of MSVC 2022 dynamically.

You software may experience intermittent crashes which you will have a hard time tracking and fixing.

On top of that (I'm not sure about this one) - not all MS DLL are redistributable. Which means you will be violating the law of the Copyright.

So, you can link wx statically, but please use dynamic linking of the CRT.

I hope someone can correct me on the licensing point of MSVC CRT if I am wrong.

Thank you.

[RLWA32]

If an .exe is created that is statically linked to the CRT and the wxwidgets static libs that are used are also statically linked to the same CRT then there should be no issue. Its completely self-contained. That a user of the .exe has different versions of the VC++ runtime installed is not relevant.

Building a DLL that is statically linked to the CRT is problematic. If the wxwidgets DLLs were built by statically linking to the CRT each DLL would have its own copy of that CRT. Anything that passes CRT objects (e.g., FILE*, memory allocations, etc.) across a DLL boundary is asking for trouble.

[doublemax]

Let's say you have build you software with MSVC 2010. You link everything statically.
Imagine the situation where the user of your program have MSVC 2022 or has some software that is using Run-Time of MSVC 2022 dynamically.

You software may experience intermittent crashes which you will have a hard time tracking and fixing.

That's not correct. Statically linked CRTs don't affect other applications.

On top of that (I'm not sure about this one) - not all MS DLL are redistributable. Which means you will be violating the law of the Copyright.
I hope someone can correct me on the licensing point of MSVC CRT if I am wrong.

That depends on the compiler. If you're using a Community Version of Visual Studio, you are indeed not allowed to ship an app with statically linked CRTs.

The reason why MS strongly recommends to link CRTs dynamically is for security. If an exploit was found in a CRT, they could fix it with a Windows update, but only for dynamically linked ones.

FWIW, i use static CRT linking everywhere myself, i just like the idea of self-contained exes without external dependencies.