MSW: 3.1.2 + CMake3.19 install link errors (VS2015) (Edited: actually FindwxWidgets.cmake mostly)
MSW: 3.1.2 + CMake3.19 install link errors (VS2015) (Edited: actually FindwxWidgets.cmake mostly)
Update: I feel like I should rename this topic to emphasize "find_package/FindwxWidgets.cmake" since the link errors mostly shook out. Ticket about the find_package script: https://trac.wxwidgets.org/ticket/19144
I think I upgraded CMake a while ago and now I'm in hell trying to build static wxWidgets. The "find_package(wxWidgets COMPONENTS core base gl html REQUIRED)" isn't working so I'm trying to rebuild/install wxWidgets and that's hitting a bunch of linker errors (VS2015 edition) which I can't explain other than CMake was updated.
The only thing that looks suspicious is the following variable, since that directory doesn't exist and so it can't install the 25 out of 32 projects that do build without link errors.
CMAKE_INSTALL_PREFIX C:/Program Files (x86)/wxWidgets (Edited: I never solved this other than manually editing it away.)
I wonder if the FindwxWidgets.cmake script is no longer compatible with this version of wxWidgets? And same for its CMakeLists.txt file? Anyway, it sucks. I'm hoping someone's seen this before. I don't relish trying to update to new version of wxWidgets but maybe that's required
EDITED: By alternative means (searching for *.sln) I was able to get things working pretty easily with C:\wxWidgets-3.1.2\build\msw\wx_vc14.sln (i.e. cut CMake out of the picture) but I can't use my CMake scripts that are "shipped" with my project, so probably others will hit walls too, although I guess it depends on version compatibility randomness, so I'd like to know the score if possible.
I think I upgraded CMake a while ago and now I'm in hell trying to build static wxWidgets. The "find_package(wxWidgets COMPONENTS core base gl html REQUIRED)" isn't working so I'm trying to rebuild/install wxWidgets and that's hitting a bunch of linker errors (VS2015 edition) which I can't explain other than CMake was updated.
The only thing that looks suspicious is the following variable, since that directory doesn't exist and so it can't install the 25 out of 32 projects that do build without link errors.
CMAKE_INSTALL_PREFIX C:/Program Files (x86)/wxWidgets (Edited: I never solved this other than manually editing it away.)
I wonder if the FindwxWidgets.cmake script is no longer compatible with this version of wxWidgets? And same for its CMakeLists.txt file? Anyway, it sucks. I'm hoping someone's seen this before. I don't relish trying to update to new version of wxWidgets but maybe that's required
EDITED: By alternative means (searching for *.sln) I was able to get things working pretty easily with C:\wxWidgets-3.1.2\build\msw\wx_vc14.sln (i.e. cut CMake out of the picture) but I can't use my CMake scripts that are "shipped" with my project, so probably others will hit walls too, although I guess it depends on version compatibility randomness, so I'd like to know the score if possible.
Last edited by Mick P. on Wed Apr 14, 2021 2:32 am, edited 6 times in total.
Re: MSW: 3.1.2 + CMake3.19 install link errors (VS2015)
Code: Select all
CMAKE_INSTALL_PREFIX C:/Program Files (x86)/wxWidgets
Use the source, Luke!
Re: MSW: 3.1.2 + CMake3.19 install link errors (VS2015)
Maybe but that's not a correct path anyway... I think it's probably a default path. For the heck of it I looked in the script that comes with CMake and noticed the following:
My folder is in wxWidgets-3.1.2, so it seems like probably these are hardcoded and my version just happened to be too new... except what's baffling is the version of CMake I had installed before this one had to be older than this version. That doesn't make any sense. I think I just installed the newest version of CMake that existed... because the one I had was too old.
Either I'm nuts or maybe there's something to all this. Or maybe these hardcoded paths are just for a legacy path and something else is broken. Unfortunately I don't know how to debug CMake's modules scripts, or that would be the easiest thing. I have developed (modified heavily) CMake modules before but I can't remember if I had a debugger or just intuited my way through it with error messages.
Edited: Anyway, the notes at the top of this script (FindwxWidgets.cmake) suggest that it should work, that it expects to find my installation where it is. So, I'd say it's definitely broken. And so is it not linking broken (these are probably two unrelated problems) but I think that's a different matter. It seems like I should start by looking at reinstalling CMake. (All of this is funny because I feel like my wxWidgets install is ancient by now.)
Edited: I think I will start by editing my version into the top of that list
Code: Select all
#-------------------------------------------------------------------
# WIN32: Start actual work.
#-------------------------------------------------------------------
# Look for an installation tree.
find_path(wxWidgets_ROOT_DIR
NAMES include/wx/wx.h
PATHS
ENV wxWidgets_ROOT_DIR
ENV WXWIN
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\wxWidgets_is1;Inno Setup: App Path]" # WX 2.6.x
C:/
D:/
ENV ProgramFiles
PATH_SUFFIXES
wxWidgets-3.1.0
wxWidgets-3.0.2
wxWidgets-3.0.1
wxWidgets-3.0.0
wxWidgets-2.9.5
wxWidgets-2.9.4
wxWidgets-2.9.3
wxWidgets-2.9.2
wxWidgets-2.9.1
wxWidgets-2.9.0
wxWidgets-2.8.9
wxWidgets-2.8.8
wxWidgets-2.8.7
wxWidgets-2.8.6
wxWidgets-2.8.5
wxWidgets-2.8.4
wxWidgets-2.8.3
wxWidgets-2.8.2
wxWidgets-2.8.1
wxWidgets-2.8.0
wxWidgets-2.7.4
wxWidgets-2.7.3
wxWidgets-2.7.2
wxWidgets-2.7.1
wxWidgets-2.7.0
wxWidgets-2.7.0-1
wxWidgets-2.6.4
wxWidgets-2.6.3
wxWidgets-2.6.2
wxWidgets-2.6.1
wxWidgets-2.5.4
wxWidgets-2.5.3
wxWidgets-2.5.2
wxWidgets-2.5.1
wxWidgets
DOC "wxWidgets base/installation directory"
)
Either I'm nuts or maybe there's something to all this. Or maybe these hardcoded paths are just for a legacy path and something else is broken. Unfortunately I don't know how to debug CMake's modules scripts, or that would be the easiest thing. I have developed (modified heavily) CMake modules before but I can't remember if I had a debugger or just intuited my way through it with error messages.
Edited: Anyway, the notes at the top of this script (FindwxWidgets.cmake) suggest that it should work, that it expects to find my installation where it is. So, I'd say it's definitely broken. And so is it not linking broken (these are probably two unrelated problems) but I think that's a different matter. It seems like I should start by looking at reinstalling CMake. (All of this is funny because I feel like my wxWidgets install is ancient by now.)
Edited: I think I will start by editing my version into the top of that list
Last edited by Mick P. on Wed Apr 14, 2021 2:10 am, edited 2 times in total.
- doublemax@work
- Super wx Problem Solver
- Posts: 474
- Joined: Wed Jul 29, 2020 6:06 pm
- Location: NRW, Germany
Re: MSW: 3.1.2 + CMake3.19 install link errors (VS2015)
I don't use Cmake, but i think it's very strange that it would rely on that registry entry. Because that would only exist, if you installed wxWidgets through the Windows installer (which i don't think many people do).
Isn't there an environment variable that CMake uses to find wxWidgets?
Isn't there an environment variable that CMake uses to find wxWidgets?
Re: MSW: 3.1.2 + CMake3.19 install link errors (VS2015)
Good point, it looks pretty fragile. Of those environment variables I have "WXWIDGETS=C:\wxWidgets-3.1.2" but that's not even in its list (Assuming these are environment variables... I think so... and not CMake internal things... maybe they're both.)
Edited: Something tells me it would combine the "C:/" line with these strings and find it if it were in the list. 11/6/2020 is the file date on this script... when I installed it.
Edited: Something tells me it would combine the "C:/" line with these strings and find it if it were in the list. 11/6/2020 is the file date on this script... when I installed it.
Re: MSW: 3.1.2 + CMake3.19 install link errors (VS2015)
AFAIK, CMake's FindwxWidgets module generally relies on the environment variable WXWIN, which the programmer is supposed do set correctly, regardless of the build tool used, see wxWidgets docs.
Otherwise, you need to set wxWidgets_ROOT_DIR and wxWidgets_LIB_DIR CMake variables to point to the correct folders.
The above applies to building wxWidgets application, as building wxWidgets itself is not related to finding it.
Otherwise, you need to set wxWidgets_ROOT_DIR and wxWidgets_LIB_DIR CMake variables to point to the correct folders.
The above applies to building wxWidgets application, as building wxWidgets itself is not related to finding it.
Re: MSW: 3.1.2 + CMake3.19 install link errors (VS2015)
So I'm still going to dig into the odd dates around these seemingly incompatible versions, but for the record after adding my version to the top of the list, it was found, and to build/install wxWidgets itself I manually edited the CMAKE_INSTALL_PREFIX in CMake-GUI and deleted its cache (maybe it was using a cache from previous version of Cmake???) removed the link errors except for one module, called wxrc:
Edited: For the record wxrc/xrc does build when not using CMake's generated projects. I.e. just using the provided/equivalent SLN file.
It's possible this didn't link before since it seems to be nonessential. I'm guessing there's probably something legit wrong/out-of-date with its project. I will report back with more findings when I can (I've only lightly dealt with this tonight) but something I'm glad I managed was adding Windows XP coverage to the builds by specifying v140_xp after deleting that cache.
Anyway, I wonder what's going on here, since 3.1.2 seems like it should be on the list for CMake circa Nov, 2020. But I don't know how often wxWidgets publishes new releases or if itt was considered preliminary, although I'm certain the older version of CMake had worked with it and found the install.
Code: Select all
Line Description File
1 2 unresolved externals C:\wxWidgets-3.1.2\lib\vc_lib\wxrc.exe
1 unresolved external symbol __imp___wassert referenced in function _XML_GetParsingStatus C:\wxWidgets-3.1.2\utils\wxexpatd.lib(xmlparse.obj)
1 unresolved external symbol __imp___wassert referenced in function _XML_GetParsingStatus C:\wxWidgets-3.1.2\utils\wxexpatd.lib(xmlparse.obj)
1 unresolved external symbol __except_handler4_common referenced in function __except_handler4 C:\wxWidgets-3.1.2\utils\MSVCRTD.lib(_chandler4gs_.obj)
1 unresolved external symbol __except_handler4_common referenced in function __except_handler4 C:\wxWidgets-3.1.2\utils\MSVCRTD.lib(_chandler4gs_.obj)
1 2 unresolved externals C:\wxWidgets-3.1.2\lib\vc_lib\wxrc.exe
It's possible this didn't link before since it seems to be nonessential. I'm guessing there's probably something legit wrong/out-of-date with its project. I will report back with more findings when I can (I've only lightly dealt with this tonight) but something I'm glad I managed was adding Windows XP coverage to the builds by specifying v140_xp after deleting that cache.
Anyway, I wonder what's going on here, since 3.1.2 seems like it should be on the list for CMake circa Nov, 2020. But I don't know how often wxWidgets publishes new releases or if itt was considered preliminary, although I'm certain the older version of CMake had worked with it and found the install.
Last edited by Mick P. on Tue Apr 13, 2021 9:30 am, edited 1 time in total.
Re: MSW: 3.1.2 + CMake3.19 install link errors (VS2015)
Thanks, I don't know if I've ever heard of WXWIN before (as environment variable). In this case the script seems to use it (why do I have WXWIDGETS in my environment? maybe I made it for myself and forgot) but also uses "C:/" so that it should have found my files either way. For the record in one reply I seem to have found that the script omits this version, ostensibly because it's older than this version. That doesn't add up (maybe the CMake version is a really old "stable" version and the even older version had a less rigid script, I will try to find out tomorrow.)PB wrote: ↑Tue Apr 13, 2021 7:22 am AFAIK, CMake's FindwxWidgets module generally relies on the environment variable WXWIN, which the programmer is supposed do set correctly, regardless of the build tool used, see wxWidgets docs.
Otherwise, you need to set wxWidgets_ROOT_DIR and wxWidgets_LIB_DIR CMake variables to point to the correct folders.
The above applies to building wxWidgets application, as building wxWidgets itself is not related to finding it.
Re: MSW: 3.1.2 + CMake3.19 install link errors (VS2015)
WXWIN is mentioned all over in the wxWidgets install docs:
https://docs.wxwidgets.org/trunk/plat_msw_install.html
Re: MSW: 3.1.2 + CMake3.19 install link errors (VS2015)
Hi,
Why do you want to use CMake?
You have msvc...
Thank you.
Why do you want to use CMake?
You have msvc...
Thank you.
Re: MSW: 3.1.2 + CMake3.19 install link errors (VS2015)
It's portable across platforms like wxWidgets.Why do you want to use CMake?
For the record, here's a ticket: https://trac.wxwidgets.org/ticket/19144
Re: MSW: 3.1.2 + CMake3.19 install link errors (VS2015) (Edited: actually FindwxWidgets.cmake mostly)
Hi,
Yes, it is portable, but to do what?
You can create a simple MSVC solution and compile your code or you use the props file.
On Linux you can use Anjuta which has template to creating a wxWidgets projects.
And on OSX - use Xcode. It is well documented in the WiKi on how to create it.
No need to 3rd party software, which as you found is buggy.
Or even better solution - use CodeBlocks. Its a wxWidgets-based IDE...
Thank you.
Yes, it is portable, but to do what?
You can create a simple MSVC solution and compile your code or you use the props file.
On Linux you can use Anjuta which has template to creating a wxWidgets projects.
And on OSX - use Xcode. It is well documented in the WiKi on how to create it.
No need to 3rd party software, which as you found is buggy.
Or even better solution - use CodeBlocks. Its a wxWidgets-based IDE...
Thank you.
Re: MSW: 3.1.2 + CMake3.19 install link errors (VS2015) (Edited: actually FindwxWidgets.cmake mostly)
I'm not trying to debate that, but you give several different solutions in different settings, which is the problem CMake is designed to address, by reducing it to one system. For publishing open-source software we don't want to maintain complicated recipes for every environment (ideally we don't want to know about the environments, since some may not even have been invented yet) so instead the goal is to have one make system that's short and sweet so others have a chance of getting the software working for themselves instead of hitting a brick wall trying to install.
Edited: Note when I downloaded wxWidgets it comes with CMake files, so it follows that its maintainers really should be supporting the part of CMake that locates wxWidgets when software needs it to build itself. I'm personally unimpressed with the wxWidget's development community. I wish there were a better alternative that would give me more confidence and less troubles. (Also for the record, I didn't know there were SLN files deep inside wxWidget's install tree. Most software has abandoned that practice in favor of CMake. It takes a lot of the burden off of maintainers.)
Edited: Note when I downloaded wxWidgets it comes with CMake files, so it follows that its maintainers really should be supporting the part of CMake that locates wxWidgets when software needs it to build itself. I'm personally unimpressed with the wxWidget's development community. I wish there were a better alternative that would give me more confidence and less troubles. (Also for the record, I didn't know there were SLN files deep inside wxWidget's install tree. Most software has abandoned that practice in favor of CMake. It takes a lot of the burden off of maintainers.)
Re: MSW: 3.1.2 + CMake3.19 install link errors (VS2015) (Edited: actually FindwxWidgets.cmake mostly)
Hi,
What I am trying to point out that different OS/environment require to use different compilers - it doesn't matter how you create a Makefile.
Besides - this thread is talking about MSVC/Windows. It doesn't mention anything about anything else.
Also - see below.
All you do is create a binary distribution for Windows with the installer. Create an RP/DEB solutions for *nix and make an Application Bundle for Mac.
Then you set all 3 of them on the Web for your user to download. There is no need for them to build your software.
Users are "dumb" and therefore you will end up fixing the build issues instead of working on the actual bug problems in the code.
Especially if you want "one environment fits all" solution.
On top of that - just like you - people are rarely read the documentation. Otherwise you would find the MSVC solutions to build the library itsekf AND the samples.
The CMake portion of the library is NOT the same as the script that is used inside CMake to create Makefile for your software - it is made independently of wxWidgets team and it is maintained by CMake people. wxWidgets team is responsible only for the CMake script that builds wxWidgets.
So - do we want to take you seriously?
Thank you.
I understand. However CMake is not a compiler - it is merely a tool to generate the Makefile/solution that will be used later in order to compile the code.
What I am trying to point out that different OS/environment require to use different compilers - it doesn't matter how you create a Makefile.
Besides - this thread is talking about MSVC/Windows. It doesn't mention anything about anything else.
Also - see below.
You will not publish any "complicated recipes".Mick P. wrote: ↑Thu Apr 15, 2021 4:56 am For publishing open-source software we don't want to maintain complicated recipes for every environment (ideally we don't want to know about the environments, since some may not even have been invented yet) so instead the goal is to have one make system that's short and sweet so others have a chance of getting the software working for themselves instead of hitting a brick wall trying to install.
All you do is create a binary distribution for Windows with the installer. Create an RP/DEB solutions for *nix and make an Application Bundle for Mac.
Then you set all 3 of them on the Web for your user to download. There is no need for them to build your software.
Users are "dumb" and therefore you will end up fixing the build issues instead of working on the actual bug problems in the code.
Especially if you want "one environment fits all" solution.
On top of that - just like you - people are rarely read the documentation. Otherwise you would find the MSVC solutions to build the library itsekf AND the samples.
Yes, wxWidgets does come with CMake. However it is added very recently and used for building the library itself and not your software.Mick P. wrote: ↑Thu Apr 15, 2021 4:56 am Edited: Note when I downloaded wxWidgets it comes with CMake files, so it follows that its maintainers really should be supporting the part of CMake that locates wxWidgets when software needs it to build itself. I'm personally unimpressed with the wxWidget's development community.
The CMake portion of the library is NOT the same as the script that is used inside CMake to create Makefile for your software - it is made independently of wxWidgets team and it is maintained by CMake people. wxWidgets team is responsible only for the CMake script that builds wxWidgets.
Well, all you do is complains. You don't even want to make a simple test case to report a bug in the libraryMick P. wrote: ↑Thu Apr 15, 2021 4:56 am I wish there were a better alternative that would give me more confidence and less troubles. (Also for the record, I didn't know there were SLN files deep inside wxWidget's install tree. Most software has abandoned that practice in favor of CMake. It takes a lot of the burden off of maintainers.)
So - do we want to take you seriously?
Thank you.