Linking problems with static MSVC projects. (Issue #22223)
Leonardo Silva
Yesterday I spent the whole day trying to figure out why I couldn't use vcpkg STATIC triplet of wxWidgets because everytime I tried to link, I'd get a ton of missing symbols. Then I proceeded to download source from your website and compiled and linked with the Hello World example statically just fine...
... until I tried to change Hello World to use the static Runtime (/MT) and (/MTd) libraries as well. Then all broke again. I figured out that all projects in your deploy, (at least the ones linked to wxwidgets\build\msw\wx_vc16.sln) are set to link using /MD and /MDd even to static library versions, hence causing a linkage hell in projects that will use default /MT and /MTd for static linkage. For instance, every package I build with vcpkg statically will use static runtime also.
So I went to change your projects to use /MT and /MTd (instead of /MD and /MDd), and what happens is that even doing this, I will still get missing symbols for the Hello World when compiling with /MT.
So I'm out of ideas now. Am I missing anything here? Why set STATIC libraries of your project to link with Dynamic runtime?
Anyway...
Thanks.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Igor Korot
--
You received this message because you are subscribed to the Google Groups "wx-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-dev/wxWidgets/wxWidgets/issues/22223%40github.com.
VZ
Sorry, I don't understand what is this about and what is your actual problem. Things are really very, very simple:
- You must use the same CRT options (
/MD[d]or/MT[d]) for both the library and your application. - You can't use
/MT[d]when using wx as DLL.
That's all.
Please reopen if you can describe the exact scenario following the guidelines above resulting in an error.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Closed #22223.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Leonardo Silva
Yes, I know, this was supposed to be simple, but unfortunatelly it is not. I'm not sure if you understood the whole text, but I'll try again:
- If you try and build ALL your project (including libraries, wxwidgets, etc) using /MT flag, you get missing symbols, no matter what. That forced me to link my project to CRT dynamically (/MD), even when using your STATIC versions of the library. That was the ONLY way it worked until now.
This is your wxwidgets default configuration - from the download package:
See the problem here? It is linking to the DYNAMIC CRT. And that config is part of the STATIC library.
Notice the configuration set to Release over there? Now compare to your DLL Release configuration:
See the DLL Release over there? Ok, this is the first problem: why did you set everything to link DYNAMICALLY to CRT, when default static packages are supposed to link to the static CRT? You see, every package from x64-windows-static triplet on vcpkg will build with these configs:
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE static)
set(VCPKG_LIBRARY_LINKAGE static)
Emphasys on VCPKG_CRT_LINKAGE static. This alone creates a problem, because your MSVC version diverts from default linkage.
Second problem: if you go and change the (first image) version to use /MT, it compiles, fine... but now you won't be able to build your project anymore, because all you'll get are missing symbols from wxwidgets to any code compiled also with /MT. Don't ask me why, I tested this toroughly during a day and got the same results anywhere. Hence why I opened this issue.
Hope I could make things clearer now. Anything just ask...
But as I already said:
you can create a MSVC solution from the beggining, go to your website, paste the code from the Hello World app there, and then try to build it ALL (including wxwidgets) with /MT and you'll see what happens. Don't use CMAKE or anything like that. Use the project attached on $wxwidgetsDir$\build\msw\wx_vc16.sln. Don't link to any DLL, link to the static .libs.
Thanks.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Reopened #22223.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
First problem is not a problem at all but a choice. We use /MD[d] because it's the configuration recommended by Microsoft and because of the other advantages. If you need /MT, you're free to build from the command line (nmake RUNTIME_LIBS=static ...) or change the projects. But, to be clear, what you call "first problem" is simply not a problem nor a bug and will not be changed.
Second problem would be a bug, but could also be due to forgetting to change the build options for some project(s). Did you select all of them before changing the option in the IDE? Again, the official way to build with /MT is to use nmake, maybe you should try this.
If you can confirm that you did change the option to /MT for all wx projects and also use it for your application, please show the (first few, if there are many of them) errors you're getting to give us at least some information about what's actually going wrong.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
Second problem: if you go and change the (first image) version to use /MT, it compiles, fine... but now you won't be able to build your main project anymore, because all you'll get are missing symbols from wxwidgets. That happens to any code compiled also with /MT. Don't ask me why, I tested this toroughly during a day and got the same results anywhere. Hence why I opened this issue.
I just tried this and it works fine for me. Steps I performed:
- open
build\msw\wx_vc17.slnand change/MTto/MDinReleaseandDLL Releaseconfigurations of all projects. - build
ReleaseandDLL Releaseconfigurations of all projects. - open
samples\minimal\minimal_vc17.slnand change/MTto/MDinReleaseandDLL Releaseconfigurations ofminimalproject. - Build
ReleaseandDLL Releaseconfigurations ofminimal.
The static build works directly.
The dynamic build complains about missing the wx dll's because those are in a different directory. In VS, change Debugging -> Working Directory to .\..\..\lib\$(wxOutDirName). Or when running stand-alone just move the exe and dll's into the same directory.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Leonardo Silva
Thanks vads (sorry about reopening, but I didn't know how to or had permissions to that). Yes, I did change all configurations to /MT in all files. I'll show you:
These are the screenshots of my project. I'll paste them side-by-side as I see them now:
Main Project
NscLib (A compiler library I adopted)
PCRE2 (Regex engine - I had to fallback from vcpkg for now because of this issue with wxwidget, hence I made my own subprojects)
lib-pcre8
lib-pcre32
lib-pcre16
Now, onto wxwidgets:
I'll summarize, because all of the subproject configs are the same:
And this is what I get as a result:
Well, now if I go back and change EVERYTHING to /MD...
Here, live for you guys to see.
@MaartenBent mentioned he didn't have any issues with wx_vc17.sln. Problem is: my package don't even contains that .sln file. I just downloaded from here to make sure and yes, it DOES NOT have a Visual Studio wx_vc17.sln there:
https://github.com/wxWidgets/wxWidgets/releases/download/v3.1.5/wxWidgets-3.1.5.7z
So I guess where you got your package. Maybe this can help me also.
Thanks.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Leonardo Silva
PS: your download page is pointing to that package I mentioned:
https://www.wxwidgets.org/downloads/
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Leonardo Silva
PS2: as for Microsoft suggesting linking dynamically... well, I didn't know that. But then they made a problem for themselves because their package manager is set to link statically. lol... =\
Anyway, if you guys help me solve this, I can work out the vcpkg issues with MS team later. Maybe I'll just create a custom triplet and tell my (dev) colaborators to use it instead of the defaults.
Thanks.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Leonardo Silva
One last detail... this is the only code I am using from you up to now. Extracted from an example:
void Plugin::InitWxWidgets() { _PseudoApp = std::make_unique<wxApp>(); // Need a wxApp to use the widgets, even not having a main function wxEntryStart(DllHModule()); // Also need an Entry point defined, even if we already past that. _MainWindow.SetHWND(reinterpret_cast<WXHWND>(NotepadHwnd())); _MainWindow.AdoptAttributesFromHWND(); wxTopLevelWindows.Append(&_MainWindow); // ... from here on is my own stuff, nothing related to WX. }
And that's it. It compiles on /MD but not on /MT.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Leonardo Silva
Ok, after quite some time I found out I had to manually add rpcrt4.lib to my library dependencies, because that's some features your code uses to do some RPC stuff with OLE objects in that Uuid.cpp file. Still have no clue why I had to include that manually... wasn't this supposed to be handled inside the wxwidgets compilation alone and leave it transparent to the "final user" (me)?
Anyway... I'll let this open if you want to take a closer look on this. I feel this shouldn't be happening to someone just trying to download the library and use it out of the box, like I tried to do.
Cheers.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
Ok, after quite some time I found out I had to manually add
rpcrt4.libto my library dependencies, because that's some features your code uses to do some RPC stuff with OLE objects in that Uuid.cpp file. Still have no clue why I had to include that manually... wasn't this supposed to be handled inside the wxwidgets compilation alone and leave it transparent to the "final user" (me)?
I do not think that is how it works for the static builds. Did you try to build your application without linking e.g. to comctl32.lib? In a generated MSVS project, the common Windows libraries are usually inherited from the parent/project defaults, so the user does not need to add them. However, rcpt4 is not one of those libraries.
AFAIK, wxWidgets will add rcpt4 with MSVS automagically if you use CMake, include MSVS-specific setup.h, or add wxwidgets.props. If you set up the project manually, you have to make sure all the required libraries are listed. Unfortunately, AFAICT the list of these libraries is not officially documented; however, it is easy to deduce when looking for example at FindwxWidgets.cmake:
https://github.com/Kitware/CMake/blob/289ac21a469cbd97f0917669f027fb9d8c3f1b67/Modules/FindwxWidgets.cmake#L443
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Leonardo Silva
@PBfordev after trying for a while the static linkage, I decided to stick with vcpkg and adopted dynamic CRT linkage. It uses CMake internally, so it would satisfy all the criteria you guys wanted me to use.
So, I built a custom triplet using all libraries linking dynamically with CRT while building static versions (as Vad said it was recommended for this project).
In my triplet, I used this exact configs:
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE static)
set(VCPKG_CMAKE_CONFIGURE_OPTIONS "-DwxUSE_SOCKETS=0" "-DwxUSE_IPV6=0" "-DwxUSE_FS_INET=0" "-DwxUSE_PROTOCOL=0" "-DwxUSE_URL=0" "-DwxUSE_ALL_THEMES=1" "-DwxUSE_WINSOCK2=0" "wxUSE_OLE_AUTOMATION=0")
And then was when I got the same Uuid missing symbols I was getting previously. I hadn't get these while building your libraries from source (downloaded from wxwidgets page) and linking dynamically, only when I tried static; but now everything changed, because I started to build the with the dynamic CRT linkage and the same symbols showed up, ONLY because I switched to vcpkg. That didn't make sense to me, so I dig into the code until I found exactly which header you were using <rpc.h> which lead to the missing library.
Indeed my "application" doesn't link with much stuff, because it's not a FULL application, it's just a plugin for Notepad++, hence a single DLL file, with a very simple and defined interface to the host program, hence no need to worry too much about CRT versioning, data exchanging, etc. This is why I didn't want any dynamic links, because I was afraid many of my users would be forced to install C++ runtime, and that, for my project would be a disaster (imagine deploying a single DLL bloated with external code, resources and dependencies...).
But now, even knowing where to link, I didn't fall back to static (yet). Have much stuff to catch up, because I spent the last couple of days just trying to make things work for me here... but later I will certainly try again. And can report back if you wish. Anyway...
Regards.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
wxWidgets vcpkg package is maintained by Microsoft, not the wxWidgets team; therefore all vcpkg-related issues (e.g., a required library is allegedly missing in linker settings after install & integrate) must be raised at https://github.com/microsoft/vcpkg/issues
As I already wrote: When using CMake with wxWidgets-supported way (e.g., with find_package() or add_subdirectory()) or setting the MSVS project with the other two ways I mentioned above, I believe the library is added automatically.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Leonardo Silva
@PBfordev I know... back in my first post, I wasn't even refering to vcpkg I was using the pure downloaded MSVC solution file. Vcpkg was AFTER I found out what was wrong (missing a library).
But I'll try again later. So I think I'll just close this issue for now. Anything I'll report back in another thread if necessary.
Thanks.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Leonardo Silva
Closed #22223.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
AFTER I found out what was wrong (missing a library).
But that was because you set up an MSVS project for your application manually without any wxWidgets help (e.g., including MSVC-specific setup.h which autolinks all necessary libraries) and did not add a required library (see my explanation in my first post in this thread)?
Or am I missing something and there is a real issue (aside possible vckpg one)?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Leonardo Silva
I followed every direction the build document stated, yet I got that error with the original package when not building with /MD flag.
I notice my project link with very few libraries indeed. Even to use a tab control I had to declare things like this:
#pragma comment (lib, "version")
#pragma comment (lib, "comctl32")
#pragma comment (lib, "shlwapi")
#pragma comment (lib, "rpcrt4")
Or else some of my functions would break. The last one (rpcrt4) was because wxwidgets.
And even when I created a new project from zero (using only the WindowsProject template from MSVC and nothing else), the static linking would still complain about those symbols up there. So I guess maybe, yes, there's an issue with the MSVC distro. But since most people already have lots of packages embbeded in their projects they end up not noticing this.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
This has nothing to do with "having packages embedded" (whatever this means). If you use functions from some system DLL, you have to link with the corresponding import library, whether you use them directly or by linking with static wx libraries using them. And yes, this is required and perfectly normal.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Leonardo Silva
It obviously has. If a project uses a ton of libraries and you are linking to every single bit of code in the world, chances are that you won't have left any gaps to get missing symbols anymore. Anyway, enough of this. Issue is solved now. Thanks for the help and goodbye.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.