Qt6 Development

[Paul Smedley]

Yeah this does make the tests pass. Interesting, the original changes to qstringconverter.cpp also pass. Committed to main, I'll cherry-pick to 6.8.x when I get a moment

[Rich Walsh]

Yeah this does make the tests pass. Interesting, the original changes to qstringconverter.cpp also pass. Committed to main, I'll cherry-pick to 6.8.x when I get a moment

The tests that failed were passing multi-byte UTF8 characters to the converter as "native encoding". The converter thought they were a series of CP850 codepoints and converted each one of the bytes to Unicode. Most of these tests were invalid anyway since CP850 doesn't contain some of the test characters such as a non-breaking space.

Still, I think that at least one of the tests in the revised version should still fail. Could you post the new binary?

[Paul Smedley]

I refreshed https://smedley.id.au/tmp/tst_qstringconverter.zip

[Paul Smedley]

FWIW - currently updating main to 6.2.12 and 6.8.x to 6.8.3.... Seems it's been 3 months since I touched Qt.... using GCC 15.1.0 to build.

[Paul Smedley]

Well surprise, surprise, qt 6.8 is still failing with:

Code Select Expand

Assertion failed: _UM_CRUMB_STATUS (crumb) == _UMS_FREE, file ./libc-0.1.13/src/emx/src/lib/malloc/ifree.c, line 30


TRP attached. I should probably do a debug build to make the TRP more useful. I'll have to dust my notes off from when I was last conversing with Steven around this TRP.

[Martin Iturbide]

Hello Paul

First, sorry for this shameless request from my side, like if it easy.This is just a suggestion and I want to ask your opinion.

Since Qt6 has some LTS releases , how do you see the idea of trying to port "Qt 6.5.9" which is supported to 2026-03-30 and try to stabilize it (as much as possible this release), until something happens to version 6.8 which seem being hard to make it work. Or do you think it will be better to focus on 6.8 which is also a LTS release supported to 2019?

I want to see if we can finally go mainstream with Qt6 and put it on the RPM repository.

Regards

[Steven Levine]

Martin,

What is your definition of mainstream?  An rpm in some pubic repository or something else?

[Martin Iturbide]

Martin,

What is your definition of mainstream?  An rpm in some pubic repository or something else?

Yes Steven, to publish Qt6 on Netlabs RPM.

Regards

[Steven Levine]

Have you discussed the with BitWiseWorks?

[Paul Smedley]

Hello Paul

First, sorry for this shameless request from my side, like if it easy.This is just a suggestion and I want to ask your opinion.

Since Qt6 has some LTS releases , how do you see the idea of trying to port "Qt 6.5.9" which is supported to 2026-03-30 and try to stabilize it (as much as possible this release), until something happens to version 6.8 which seem being hard to make it work. Or do you think it will be better to focus on 6.8 which is also a LTS release supported to 2019?

I want to see if we can finally go mainstream with Qt6 and put it on the RPM repository.

Regards

Qt 6.2 is/was also LTS..... that was the whole point of focussing on it...

Also, whilst 6.5.9 might be the most recent COMMERCIAL release, the opensource is still 6.5.6 (https://download.qt.io/official_releases/qt/6.5). I'm not entirely sure what the benefit would be of having the core Qt libs at 6.5, and trying to blend in a 6.2 webengine....

[Martin Iturbide]

Hi Paul

In that case, do you think it will make sense to put Qt 6.2  on the Netlabs RPM?

Regards

[Paul Smedley]

In that case, do you think it will make sense to put Qt 6.2  on the Netlabs RPM?

It depends what the purpose/intent is. For getting an updated (but unstable) browser - then yes. If it's for compatibility with ported apps - I'm less sure. The DLL hell with 8.3 file names is real.....

[Martin Iturbide]

In that case, do you think it will make sense to put Qt 6.2  on the Netlabs RPM?

It depends what the purpose/intent is. For getting an updated (but unstable) browser - then yes. If it's for compatibility with ported apps - I'm less sure. The DLL hell with 8.3 file names is real.....

I think it will be more the ported apps. I know that Qt6 is not mandatory today, but Tellie is starting to port some apps with Qt6 and I think we should be moving into that. But the idea is not to break the Qt5 things that are working. If Qt5 and Qt6 can not coexist that will be a stopper.

Regards

[Paul Smedley]

Qt5 and Qt6 can coeexist fine. My comment on DLL hell was more for mixing versions of Qt6..

[Dave Yeo]

Qt5 and Qt6 can coeexist fine. My comment on DLL hell was more for mixing versions of Qt6..

There will be some binaries that will take care, one example is qmake.

Code Select Expand


L:\qt6-6.2.x\bin>which2 -a qmake*
./qmake.exe (also ./qmake6.exe, ./qmake.exe, ./qmake6.exe,
w:/usr/bin/qmake-qt5.dbg, w:/usr/bin/qmake-qt5.exe, w:/usr/bin/qmake-qt5.sh,
w:/usr/bin/qmake.exe, w:/usr/bin/qmake-qt5.exe, w:/usr/bin/qmake.exe) 10


Code Select Expand


L:\qt6-6.2.x>qmake --version
QMake version 2.01a
Using Qt version 4.7.3 in W:\usr\lib