GIthub actions docker containers (for windows build)

Paul Buxton paulbuxton.mail at googlemail.com
Sun May 31 02:53:41 PDT 2020


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 <dirk at hohndel.org> 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 <
> paulbuxton.mail at googlemail.com> 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 <
>> paulbuxton.mail at googlemail.com> 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, <dirk at hohndel.org> 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 <salvador.cunat at gmail.com>
>>>> wrote:
>>>>
>>>> Hi Dirk, Paul
>>>>
>>>> El mar., 26 may. 2020 17:30, Dirk Hohndel via subsurface <
>>>> subsurface at subsurface-divelog.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200531/dcc33bac/attachment.html>


More information about the subsurface mailing list