QT 5.13 on Windows/MXE

[Dirk Hohndel]

> On Sep 2, 2019, at 2:23 AM, Paul Buxton <paulbuxton.mail at googlemail.com> wrote:
> 
> I notice that there is a PR for 5.13 on Mac build. I assume this means that people are using 5.13 fine on Linux? 

Yes, I use it here on Arch Linux for example. I also build my local Mac builds against Qt 5.13 - but ran out of time dealing with Travis as I have always 20 other, more urgent things to work with, like right now getting the Linux AppImage to be based on Qt 5.12 (I haven't even tried 5.13 there as no one has reported being able to get Qt 5.13 to work at all on Trusty, which is where we are building the AppImage)

> The reason I ask is that the Windows MXE build looks like it has some issues on QT 5.13, which is what the head of MXE fetches.

MXE has a tendency to break things for us - so we pick a certain version that works for us (that's in the Docker container that we use - currently it's 9f6b9c6f
I haven't played with the latest head in a while

> If I go to the import from dive computer dialog, and change the vendor, it generates an exception.
> I think it might be because we are trying to access the selected product before it has been populated, but my Qt-fu is not strong enough to be certain yet, and the latest MXE doesn't support building Debug-and-Release for the QT libraries so it isn't clear exactly where the exception is being generated.

I find debugging MXE based binaries very, very painful.
Do you have any more information from the Windows event system? One often can get at least a stack trace from that which usually helps.

> If I change my MXE toolchain to the last tagged version then it looks to work fine.
> 
> Anyone come across anything similar?

I haven't tried it.

/D