-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
win10 native MSYS2 build make package error #714
Comments
It needs some plug-ins:
|
Got passed that one only by putting Next one: Plugin not found, cannot call locate::_Open Error in macro locate::Open on macroline 1 Error in script "C:/msys64/usr/local/build/_CPack_Packages/win64/NSIS/project.nsi" on line 1133 -- aborting creation process |
You may find that you need to build 32-bit rather than 64-bit to get things to work. Launch the In the current build system, where CMake drives CPack drives NSIS, there are limits to what we can control (or at least work out what to control). Perhaps in future if we're driving NSIS directly it will be easier to fine-tune it. |
Ok, installed all |
Packaged version crashes App upon export of records. |
What about if you do a direct local install?
If that works, then we know the problem is with the packaging. If it doesn't then it would point us to looking elsewhere. |
Indeed, direct local installs work just fine with both |
OK, that's good to know. Thanks for all your efforts here. So, my best guess at the moment is that we're missing something vital from the package. I imagine, somewhere soon after Line 1289 in e92a594
You'll see from looking at the code both the advantage and the disadvantage of using CPack. The plus is that it does a lot of boilerplate work for you so, in theory, you have very little work to do to create installers and packages across all 3 platforms (Windows, Mac and Linux). The minus is that it's easy to hit edge cases where it seems hard to get the end result that you want (see endless comments in the Mac section for example) and all the wizardry going on under the hood makes it a bit tricky to debug. |
I'm trying to get Visual Studio builds going to see if its any different. My win10 has VS2017 and lots of cygwin and other downloaded binaries in the paths, so I don't know how reproducible anything coming from it could be. The win11 has virgin installs of these tool chains but VS2022---argh!--- is not as friendly. (Microsoft stuff and I have had a torrid relationship for years.) |
Didn't get very far this week with a VS2022 build kit in just trying to get xerces-c and xalan-c built from source. At one point I had them both configured with cmake, xerces-c built and installed, but the more ran down build issues with xalan-c, the more new errors popped up. MS stuff... I noticed the |
I just looked at a trial of PE Explorer. In the Dependency Scanner, when I hit xerces-c-3-2.dll it showed version info not available. This was one of the more new errors I mentioned. Here is the report: For the directly installed version, compare this report: I will put them in a side by side spreadsheet and analyze ... |
Disappointing it show anything differential but here it is. |
That seems like a promising line of enquiry. The fact that the thing works on the build machine but not when it's installed from package makes me think that we're missing something, perhaps a DLL, from the package. If this output gives us clues about which DLL or DLLs that might be, a first thing to try might be manually copying additional DLLs into |
I am, by the way, attempting to come at things from the other direction. In my new experimental build system, I have a couple of scripts that build the Windows package manually (or rather invoke NSIS manually) rather than doing things via CPack (which is more automated but gives you less control). If I can get that building, that will give me a list of the DLLs I needed to include to get it to work. We can then try adding that list to the CMake scripts we currently use for packaging. |
So, I've now reached a very interesting point. I have two build systems running side-by-side, old and new. Installing the packages from them gives different results. On the old (ie current CMake/CPack) build system, I can reproduce the problem - exporting to XML causes a crash without much useful diagnostics. On the new (ie Meson + Python) build system, I can't reproduce the problem - exporting to XML and importing from XML seems to work fine. Here's what gets installed in the bin directory from the installer generated by the "old" build system:
And here's what gets installed from the installer generated by the new build system:
(I'm doing the work in Brewken, but the "old" build system and most of the code is identical with Brewtarget.) This is after I added all the "extra" DLLs to the old build system. So, even though we're now installing pretty much the same DLLs between the two systems (in fact even a couple of extra ones for the old system), we're still seeing the different behaviour. To me, from the listings above it looks like the biggest difference is now the size of the main executable: 9,817,102 bytes for the old build and 246,042,644 bytes for the new one. I'm guessing that somehow on the "new" build we're managing to link more in statically than on the "old" one. |
I'd like to find a fix that patches up the existing build system. It feels wrong to completely change how we do build and packaging for a point release (ie 3.0.5 -> 3.0.6). In theory, I can just see what build and link flags are being emitted by both systems and then reverse-engineer the CMake settings to make it do the same as the Meson ones. In practice, I don't know whether it will be that simple. Let's see. What I probably will do in parallel is port the new build system across to Brewtarget. This is not as scary as it might sound. The new build system does not modify the old one and can happily run along side it, not least because all the output goes in a different directory ( |
I came across this bug report for |
Oh, that's interesting. Will have to check the compiler flags. I would think it would not be the cause of our problem, but it might perhaps be why we aren't getting great diagnostics from the crash. |
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Link-Options.html#Link-Options under
|
Don't know why but line 37 is the only one in 36 set(CPACK_OBJCOPY_EXECUTABLE "V:/msys64/ucrt64/bin/objcopy.exe") I also saw the note in Nevertheless .exe size of direct install and package install are still way different. |
Yes, I don't know what the heuristics are in CPack for locating these things. It's one of the pain points of using CPack: the automation saves you a bunch of effort when it works, but can be a bit cryptic to debug when it doesn't. For the executable size, I'm also starting to wonder if the difference in size is to do with including/excluding debugging symbols. |
This is from a Linux build, but shows the difference in size between a binary with and without debugging symbols:
|
Starting running my builds from last night with the current upstream this morning. My MINGW32 package build does not crash the App when exporting single hop and yeast xml records!! I'll test some more later. Pretty clean log file and no Events logged. I had edited the full paths of What's your package build do now? |
That sounds like good news! |
Sorry for long radio silence on this. You should be able to build on Windows MSYS2 with meson, and then create packages using the
As ever, give us a shout with questions or problems, either by reopening this issue or raising a new one. |
Ran into error running
cmake --build . --target package
(@matty0ung that is confirmed a good command instead of defaultmingw32-make package
)From the log NSISOutput.log
!include: could not find: "Locate.nsh"
Error in script "C:/msys64/usr/local/build/_CPack_Packages/win64/NSIS/project.nsi" on line 1008 -- aborting creation process
The text was updated successfully, but these errors were encountered: