Qt6 Development

[Paul Smedley]

OK, the TRPs with 6.4.3 and 6.5.0 are driving me nuts. I'm going to try and stabilise the qt 6.3.2 webengine and fix and traps there. That might shed some light on stuff I've missed...

Hi. Sounds like a great plan to me. Just keep pushing out the 6.3.2 releases and I will try it out.

Well step 1 was to rebuilt 6.3.x - and install to /qt6-6.3.x to ease the pain of having multiple versions to test.... However - rebuilding with GCC 12 is resulting in a qt6core.dll that is crashing when applications try and use it, for reasons I don't yet understand <sigh>

[Dave Yeo]

Optimization bugs?

[Paul Smedley]

Optimization bugs?

Perhaps - so I tried a rebuild with gcc 9.2.0 - and I'm getting a similar error. Also built on a different box (bare metal vs VM) and got the same error.

Going to go back and look at recent qtbase checkins and see if I inadvertently broke something...

I'm seeing errors like this:

Code: [Select]

{0}[u:\dev\qt6-base-os2-6.3.x\build] chkdll32 bin\uic.exe
Loading DLL 'libcn0' --> C:\USR\LIB\LIBCN0.DLL.
Loading DLL 'libcx0' --> C:\USR\LIB\LIBCX0.DLL.
Loading DLL 'Qt6Core' --> NOT loaded!
Unable to load DLL 'Qt6Core'.  DosLoadModule returned: 87
OS/2 reports '' contributed to the failure.
Loading DLL 'gcc1' --> C:\USR\LIB\GCC1.DLL.


[Rich Walsh]

I'm seeing errors like this:

Code: [Select]

Loading DLL 'Qt6Core' --> NOT loaded!
Unable to load DLL 'Qt6Core'.  DosLoadModule returned: 87
OS/2 reports '' contributed to the failure.


There's only one reason competent code like chkdll32 would generate an "Invalid parameter" error (rc=87) for this call: the module name it's supplying doesn't point to a valid DLL. IOW, you probably have a linker problem that's generating a dud dll. Run 'exehdr' against Qr6Core to see if it recognizes the file as being a dll.

[Paul Smedley]

I've attached exehdr output for the 'good'and 'bad' builds.

[Paul Smedley]

The 'good' news is that it's something particular to the 6.3.x  code - I just rebuilt qtbase 6.4.3 and the DLL is fine. Will investigate this afternoon after my specialist appointment.

[Rich Walsh]

I've attached exehdr output for the 'good'and 'bad' builds.

I was expecting some simple-minded cause but it looks like you're in Steven-territory now. Beside the obvious differences in file sizes, I see that some functions differ in size, mostly larger but some smaller  Were these builds created with the same gcc version and the same optimization level? I tried sorting both listings by offset to look for significant size differences (and found some) but if they're built from different codebases then doing so doesn't prove much since intervening non-exported functions may have been added or removed. You may have to ask Steve to trace the load in his trusty kernel debugger to see why it fails.

[Paul Smedley]

Thanks Rich, I've pestered Steven enough recently that I'll do some more local investigation first before I bug him!!

First thing I'll try is using Unix makefiles rather than Ninja.

Edit: OK that didn't help - will example compiler flags between 6.3.x and 6.4.x

[Paul Smedley]

re: javascript issues in 6.4 - pretty sure these are due to the stubs in https://github.com/psmedley/qt6-webengine-os2/blob/6.4.x/src/3rdparty/chromium/v8/src/base/platform/platform-os2.cc#L205 from lines 205 downwards. These may also be the cause of the mksnapshot crash in 6.5

[Paul Smedley]

I know I've been a bit quiet the last couple of weeks, I've needed some time away from Qt6 as it was starting to frustrate me.  I also went away last weekend, and picked up a new car this week. The weather this weekend is pretty miserable (http://www.bom.gov.au/places/sa/henley-beach/) so I might look into some of the webengine issues later today.

[Paul Smedley]

The commit at https://github.com/psmedley/qt6-webengine-os2/commit/55f25c9d40d0f5299839679481892fe3f07469db works around a TRP on OS/2 - in some cases, cache_handler is NULL (no idea why yet). For now, if this is try, we don't try and run the caching code.

After fixing this, I found a TRP in the audio code, which is fixed in https://github.com/psmedley/qt6-webengine-os2/commit/c08132e97ddd6445abb071d0d2ece0bb704aa336

The trp is because on one machine, kaiOpen fails, but then the code further on uses values which are only available if the kaiOpen call succeeds - so we get a SIGFPE.

With the latest commits, I'm able to watch some video in simplebrowser, albeit with no sound on the VM I was using to test.

[Paul Smedley]

Hey all... I cobbled together a local build of dav1d and am able to generate a DLL that will play AV1 video for me

There are some nasm warnings during compilation:

Code: [Select]

../src/x86/msac.asm:29: warning: OBJ format does not support alignment of 64: rounding up to 256 [-w+other]
U:/DEV/dav1d-1.2.0/src/ext/x86/x86inc.asm:93: ... from macro `SECTION_RODATA' defined here [-w+other]
../src/x86/msac.asm:69: warning: segment attributes specified on redeclaration of segment: ignoring [-w+other]
../src/x86/msac.asm:73: warning: segment attributes specified on redeclaration of segment: ignoring [-w+other]
U:/DEV/dav1d-1.2.0/src/ext/x86/x86inc.asm:102: ... from macro `SECTION_TEXT' defined here [-w+other]

x86inc.asm:93 is the obj code from:

Code: [Select]

%macro SECTION_RODATA 0-1 16
    %ifidn __OUTPUT_FORMAT__,win32
        SECTION .rdata align=%1
    %elif WIN64
        SECTION .rdata align=%1
    %elifidn __OUTPUT_FORMAT__,obj
        SEGMENT TEXT32 CLASS=CODE USE32 ALIGN=%1
    %else
        SECTION .rodata align=%1
    %endif
%endmacro
x86inc.asm:102 is the obj code from:

Code: [Select]

%macro SECTION_TEXT 0
    %ifidn __OUTPUT_FORMAT__,obj
        SEGMENT TEXT32 CLASS=CODE USE32
    %else
        SECTION .text
    %endif
%endmacro

Any ideas?

[Dave Yeo]

Wonder about building it in aout mode, -f aout? Nice and simple, x86inc.asm should have the macros and should only take minor patching following whatever Mach does. Should work fine if only LDFLAGS has -Zomf for a standalone DLL.
Which source did you use, I might try

[Paul Smedley]

Hey Dave,

I used meson 0.49.2 and the dav1d 1.2.0 source

the dav1d meson.build knows nothing about OS/2 - so defaults to elf32 and funky ld parameters that our ancient ld doesn't understand, so I manually hacked some bits of ninja.build

I'll try a.out....

[Paul Smedley]

with aout:

Code: [Select]

FAILED: src/25a6634@@dav1d@sha/msac.obj
C:/USR/BIN/nasm.exe -f aout -I U:/DEV/dav1d-1.2.0/src/ -I U:/DEV/dav1d-1.2.0/build/ -MQ src/25a6634@@dav1d@sha/msac.obj -MF src/25a6634@@dav1d@sha/msac.obj.ndep ../src/x86/msac.asm -o src/25a6634@@dav1d@sha/msac.obj
../src/x86/msac.asm:29: error: segment name `.rodata align=64' not recognized
U:/DEV/dav1d-1.2.0/src/ext/x86/x86inc.asm:95: ... from macro `SECTION_RODATA' defined here
../src/x86/msac.asm:69: error: segment name `.rodata align=64' not recognized