So I think I have resolved most of the issues I was finding, still (at least) one more however :-)
We seem to have developed a dependency on libzstd.dll I think this is a new dependency of qt from 5.13 onwards. This wasn't picked up in the build, but when I run it is reported as an error. Currently libzstd.dll is not generated in MXE, but it looks like someone filed a pull request that fixes that 5 days ago, but as of this morning it hasn't been merged. When that is available I will see if I can get something that actually executes. Not sure if I will need to manually add the dll as an install file, or if it will automatically be picked up.. I contacted the MXE mailing list about getting cmake updated, and they were quite helpful, there is a mechanism in MXE for trying updated packages of things in MXE, so I will try building with an up to date CMake/ In the meantime my branch has the modified findpkgconfig.cmake added to the container build. I will send a draft pull request in case anyone wants to make sure I am not going in completely the wrong direction. Paul I am going to file a draft pull request so you can On Thu, May 28, 2020 at 6:53 PM Dirk Hohndel <[email protected]> wrote: > I'd start with b, then d > > 5.15 is something we'll need to get to eventually. > In the past there was an MXE contributor who tended to work on that, maybe > reach out to them as well. > > > /D > > > On May 28, 2020 9:39:32 AM PDT, Paul Buxton < > [email protected]> wrote: >> >> So down the rabbit hole! >> >> Taking a reasonably up to date version of MXE we hit a bug in Cmake 3.15 >> where when specifying a PKG_CONFIG_PATH with multiple folders in the path >> and cross compiling to windows (on a Linux host) it incorrectly swaps the : >> with a ; so pkg-config only searches the first entry on the path. >> This issue has been fixed in CMake 3.17. >> >> So should I, >> a) Try getting cmake manually of a version we choose >> b) Patch the cmake we have in the container (it's a 1 line fix) >> c) Get MXE to use the newer cmake >> d) Get MXE to cherry pick the fix >> e) Something else >> >> Options (c) and (d) would also end up pulling in QT 5.15, and when I >> briefly tried this yesterday it was failing to build qtbase... >> Option(a) might have other unknowns. >> Option (b) is a bit hacky :-) >> >> Any preferences? >> >> There is also an issue with missing symbol >> libglib is missing _imp__timeGetTime >> Which seems to be related to this change (or something similar) in the >> Mingw toolchain >> >> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/65042f860f8cb67b26d97fd763143946f9a7c6e6/ >> >> But I haven't figured out yet where mxe gets its mingw from, so haven't >> been able to oinpoint when/how this has been broken. >> >> >> >> >> >> On Thu, May 28, 2020 at 6:59 AM Paul Buxton < >> [email protected]> wrote: >> >>> Yeah, I saw the parameter and an using it locally, but as Dirk mentions >>> it isn't used by the build on GitHub. >>> I will include this in my changes when I get something that behaves. >>> >>> >>> On Wed, 27 May 2020, 20:00 Dirk Hohndel, <[email protected]> wrote: >>> >>>> Hi Salva, >>>> >>>> you are of course correct. And I had used a script to pass that in >>>> here, but then never checked in that script. >>>> As a result the GitHub Action happened to use 'master' - which wasn't >>>> really what I had intended. >>>> >>>> /D >>>> >>>> On May 27, 2020, at 10:52 AM, Salvador Cuñat <[email protected]> >>>> wrote: >>>> >>>> Hi Dirk, Paul >>>> >>>> El mar., 26 may. 2020 17:30, Dirk Hohndel via subsurface < >>>> [email protected]> escribió: >>>> >>>>> >>>>> The MXE version is fixed as a specific SHA. And as I grep through the >>>>> sources to refresh my memory where that's done I notice that the SHA >>>>> doesn't appear to be in the source tree. How weird. >>>>> I believe the last one that I used (based on the remnants of local >>>>> builds) was 9f6b9c6f - but I need to dig some more to figure out why this >>>>> isn't in the sources... >>>>> >>>> >>>> In aab658f we introduced a parameter for the docker build to pass the >>>> mxe git sha using --build-arg= >>>> >>>> After this change the used version is not in the Dockerfile any more, >>>> but it's manually entered while building the image. >>>> >>>> Best regards. >>>> >>>> Salva. >>>> >>>> >>>> > -- > From my phone >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
