OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: Paul Smedley on October 23, 2022, 10:02:36 am

Title: Building Qt5
Post by: Paul Smedley on October 23, 2022, 10:02:36 am
Hey All,

Given it's been a LONG time since there have been any Qt5 updates, I figured I'd start a thread on trying to build Qt5 from the sourcecode at the bww github, and attempting to follow the build instructions at https://github.com/bitwiseworks/qt5-os2/wiki/Developers#building-qt

I've previously tried building and failed, but have never documented my experience or compared it to what others have experienced.

At the moment, I'm doing a fresh checkout of the code, on a new bare metal install of AOS 5.07

More to come...

Cheers,

Paul
Title: Re: Building Qt5
Post by: Paul Smedley on October 23, 2022, 10:56:17 am
1st Issue - Build instructions at https://github.com/bitwiseworks/qt5-os2/wiki/Developers#building-qt Step 1 need to include gcc-g++, pthread-devel, gperf, bison, flex as well.
2nd issue - Reboot is required after step 2 to load config.sys parameters for GCC
3rd issue - 'SET MAKESHELL=dash.exe' needs to be set, otherwise make.exe tries to use cmd.exe
Title: Re: Building Qt5
Post by: Dave Yeo on October 23, 2022, 10:43:20 pm
I revisited, trying a rel build. It failed to detect the system libvpx, errors such as,
Code: [Select]
> main.cpp: In function 'int main(int, char**)':
> main.cpp:11:14: error: 'CONSTRAINED_FROM_ABOVE_DROP' was not declared in this
scope; did you mean 'CONSTRAINED_LAYER_DROP'?
>    11 |     auto a = CONSTRAINED_FROM_ABOVE_DROP;
>       |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>       |              CONSTRAINED_LAYER_DROP
> make.exe: *** [main.obj] Error 1
 => source failed verification.
test config.qtwebengine_buildtools.libraries.webengine-libvpx FAILED

I guess our libvpx is now too new.
The build itself failed with,
Code: [Select]
../../../../../qt5/qtwebengine/src/3rdparty/chromium/third_party/libvpx/source/libvpx/vp8/common/x86/dequantize_mmx.asm:17: error: invalid syntax in global declaration
../../../../../qt5/qtwebengine/src/3rdparty/chromium/third_party/libvpx/source/libvpx/vp8/common/x86/dequantize_mmx.asm:59: error: invalid syntax in global declaration

Which points to the QT5 tree's libvpx not being patched for OS/2. Needs x86inc.asm updated, -fobj added to nasm flags and possibly ported from YASM to NASM, basically the equivalent of adding a trailing / to the includes might be enough.
Ideally is updating the configure script to use the system libvpx. I note that Mozilla has had success using each livvpx update with no patching required.

Edit: Looking, the system libvpx does have CONSTRAINED_FROM_ABOVE_DROP, not sure why configure failed there.
Title: Re: Building Qt5
Post by: Roderick Klein on October 23, 2022, 10:50:48 pm
Hey All,

Given it's been a LONG time since there have been any Qt5 updates, I figured I'd start a thread on trying to build Qt5 from the sourcecode at the bww github, and attempting to follow the build instructions at https://github.com/bitwiseworks/qt5-os2/wiki/Developers#building-qt

I've previously tried building and failed, but have never documented my experience or compared it to what others have experienced.

At the moment, I'm doing a fresh checkout of the code, on a new bare metal install of AOS 5.07

More to come...

Cheers,

Paul

Dmitry just finished a import QT fix related to menu;s not working. He is working on the genereal stability of the Dooble browser. As been stated his quick depeature from Russia and getting settled somewhere else in the E.U. has taken a lot of time. This has resulted in development being more or less at a standstill for about 6 months. But a fix on LIBCX has been worked on and genereal stabilisation of Dooble is being worked on.

A bug was opened by Gregg Young about how to bulld QT.


Roderick Klein
OS/2 VOICE
Title: Re: Building Qt5
Post by: Dave Yeo on October 23, 2022, 11:25:43 pm
A bug was opened by Gregg Young about how to bulld QT.


Do you know the issue number for Gregg's bug?

Title: Re: Building Qt5
Post by: Roderick Klein on October 23, 2022, 11:56:41 pm
A bug was opened by Gregg Young about how to bulld QT.


Do you know the issue number for Gregg's bug?

No sorry.

Roderick
Title: Re: Building Qt5
Post by: Paul Smedley on October 24, 2022, 09:17:50 am
A bug was opened by Gregg Young about how to bulld QT.


Do you know the issue number for Gregg's bug?

No sorry.

Roderick

Based on my review of the bww github repository, I don't believe there is a current ticket for build issues. If nobody else raises one, I'll raise one once I have a bit more worked out...

edit: https://github.com/bitwiseworks/qt5-os2/issues/31 has been raised around the wiki issues.
Title: Re: Building Qt5
Post by: Tom on October 24, 2022, 06:42:07 pm
Based on my review of the bww github repository, I don't believe there is a current ticket for build issues.

I also couln't find a ticket by Gregg Young about building problems in any of the 10 Qt5 repositories from bitwiseworks.
Title: Re: Building Qt5
Post by: TeLLie on October 25, 2022, 12:10:45 am
Hi Paul,

I dint manage also not to get is build on my new machine, on my previous W530 i where able to get it build.

Now i get some like:
Code: [Select]
[1/5669] g++ -MMD -MF obj/services/network/public/cpp/cpp_base/p2p_param_traits.o.d -DIS_NETWORK_CPP_BASE_IMPL -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DOPENSSL_NO_ASM -DUSING_SYSTEM_ICU=1 -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DUCHAR_TYPE=wchar_t -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 -DWEBRTC_CHROMIUM_BUILD -DWEBRTC_POSIX -DWEBRTC_OS2 -DWEBRTC_NO_INET6 -DABSL_ALLOCATOR_NOTHROW=1 -DWEBRTC_USE_BUILTIN_ISAC_FIX=0 -DWEBRTC_USE_BUILTIN_ISAC_FLOAT=1 -DHAVE_SCTP -DNO_MAIN_THREAD_WRAPPING -I. -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium -Igen -Igen -Igen -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/perfetto/include -Igen/third_party/perfetto/build_config -Igen/third_party/perfetto -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/libyuv/include -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/jsoncpp/source/include -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/jsoncpp/generated -Igen -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/boringssl/src/include -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/ced/src -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src -Igen/protoc_out -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/webrtc_overrides -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/webrtc -Igen/third_party/webrtc -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/abseil-cpp -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -Zomf -m32 -msse2 -mfpmath=sse -mmmx -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments -Wno-packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fomit-frame-pointer -s -I/@unixroot/usr/include/nss3 -I/@unixroot/usr/include/nspr4 -std=gnu++14 -Wno-narrowing -Wno-class-memaccess -Wno-attributes -Wno-class-memaccess -Wno-subobject-linkage -Wno-invalid-offsetof -Wno-return-type -Wno-deprecated-copy -fno-exceptions -fno-rtti -Wno-deprecated-declarations -c ../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/services/network/public/cpp/p2p_param_traits.cc -o obj/services/network/public/cpp/cpp_base/p2p_param_traits.o
[2/5669] touch obj/services/network/public/cpp/cert_verifier/cert_verifier.inputdeps.stamp
[3/5669] g++ -MMD -MF obj/services/network/public/cpp/cert_verifier/cert_verifier/cert_net_fetcher_url_loader.o.d -DIS_CERT_VERIFIER_CPP_IMPL -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DOPENSSL_NO_ASM -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD -DUSING_SYSTEM_ICU=1 -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DUCHAR_TYPE=wchar_t -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 -DWEBRTC_CHROMIUM_BUILD -DWEBRTC_POSIX -DWEBRTC_OS2 -DWEBRTC_NO_INET6 -DABSL_ALLOCATOR_NOTHROW=1 -DWEBRTC_USE_BUILTIN_ISAC_FIX=0 -DWEBRTC_USE_BUILTIN_ISAC_FLOAT=1 -DHAVE_SCTP -DNO_MAIN_THREAD_WRAPPING -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium -Igen -Igen -Igen -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/perfetto/include -Igen/third_party/perfetto/build_config -Igen/third_party/perfetto -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/libyuv/include -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/jsoncpp/source/include -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/jsoncpp/generated -Igen -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/boringssl/src/include -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src -Igen/protoc_out -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/ced/src -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/webrtc_overrides -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/webrtc -Igen/third_party/webrtc -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/abseil-cpp -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -Zomf -m32 -msse2 -mfpmath=sse -mmmx -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments -Wno-packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fomit-frame-pointer -s -I/@unixroot/usr/include/nss3 -I/@unixroot/usr/include/nspr4 -std=gnu++14 -Wno-narrowing -Wno-class-memaccess -Wno-attributes -Wno-class-memaccess -Wno-subobject-linkage -Wno-invalid-offsetof -Wno-return-type -Wno-deprecated-copy -fno-exceptions -fno-rtti -Wno-deprecated-declarations -c ../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/services/network/public/cpp/cert_verifier/cert_net_fetcher_url_loader.cc -o obj/services/network/public/cpp/cert_verifier/cert_verifier/cert_net_fetcher_url_loader.o
FAILED: obj/services/network/public/cpp/cert_verifier/cert_verifier/cert_net_fetcher_url_loader.o
g++ -MMD -MF obj/services/network/public/cpp/cert_verifier/cert_verifier/cert_net_fetcher_url_loader.o.d -DIS_CERT_VERIFIER_CPP_IMPL -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DOPENSSL_NO_ASM -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD -DUSING_SYSTEM_ICU=1 -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DUCHAR_TYPE=wchar_t -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 -DWEBRTC_CHROMIUM_BUILD -DWEBRTC_POSIX -DWEBRTC_OS2 -DWEBRTC_NO_INET6 -DABSL_ALLOCATOR_NOTHROW=1 -DWEBRTC_USE_BUILTIN_ISAC_FIX=0 -DWEBRTC_USE_BUILTIN_ISAC_FLOAT=1 -DHAVE_SCTP -DNO_MAIN_THREAD_WRAPPING -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium -Igen -Igen -Igen -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/perfetto/include -Igen/third_party/perfetto/build_config -Igen/third_party/perfetto -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/libyuv/include -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/jsoncpp/source/include -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/jsoncpp/generated -Igen -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/boringssl/src/include -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src -Igen/protoc_out -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/ced/src -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/webrtc_overrides -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/webrtc -Igen/third_party/webrtc -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/abseil-cpp -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -Zomf -m32 -msse2 -mfpmath=sse -mmmx -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments -Wno-packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fomit-frame-pointer -s -I/@unixroot/usr/include/nss3 -I/@unixroot/usr/include/nspr4 -std=gnu++14 -Wno-narrowing -Wno-class-memaccess -Wno-attributes -Wno-class-memaccess -Wno-subobject-linkage -Wno-invalid-offsetof -Wno-return-type -Wno-deprecated-copy -fno-exceptions -fno-rtti -Wno-deprecated-declarations -c ../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/services/network/public/cpp/cert_verifier/cert_net_fetcher_url_loader.cc -o obj/services/network/public/cpp/cert_verifier/cert_verifier/cert_net_fetcher_url_loader.o
during RTL pass: final
../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/services/network/public/cpp/cert_verifier/cert_net_fetcher_url_loader.cc: In function 'base::TimeDelta cert_verifier::{anonymous}::GetTimeout(int)':
../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/services/network/public/cpp/cert_verifier/cert_net_fetcher_url_loader.cc:185:1: internal compiler error: Illegal instruction
  185 | }
      | ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://github.com/bitwiseworks/gcc-os2/issues> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
[4/5669] g++ -MMD -MF obj/services/network/network_service/network_service_jumbo_9.o.d -DIS_NETWORK_SERVICE_IMPL -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DOPENSSL_NO_ASM -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD -DUSING_SYSTEM_ICU=1 -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DUCHAR_TYPE=wchar_t -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 -DWEBRTC_CHROMIUM_BUILD -DWEBRTC_POSIX -DWEBRTC_OS2 -DWEBRTC_NO_INET6 -DABSL_ALLOCATOR_NOTHROW=1 -DWEBRTC_USE_BUILTIN_ISAC_FIX=0 -DWEBRTC_USE_BUILTIN_ISAC_FLOAT=1 -DHAVE_SCTP -DNO_MAIN_THREAD_WRAPPING -I. -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium -Igen -Igen -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/perfetto/include -Igen/third_party/perfetto/build_config -Igen/third_party/perfetto -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/libyuv/include -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/jsoncpp/source/include -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/jsoncpp/generated -Igen -Igen -Igen -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/boringssl/src/include -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src -Igen/protoc_out -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/ced/src -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/webrtc_overrides -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/webrtc -Igen/third_party/webrtc -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/abseil-cpp -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -Zomf -m32 -msse2 -mfpmath=sse -mmmx -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments -Wno-packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fomit-frame-pointer -s -I/@unixroot/usr/include/nss3 -I/@unixroot/usr/include/nspr4 -std=gnu++14 -Wno-narrowing -Wno-class-memaccess -Wno-attributes -Wno-class-memaccess -Wno-subobject-linkage -Wno-invalid-offsetof -Wno-return-type -Wno-deprecated-copy -fno-exceptions -fno-rtti -Wno-deprecated-declarations -c gen/services/network/network_service_jumbo_9.cc -o obj/services/network/network_service/network_service_jumbo_9.o
FAILED: obj/services/network/network_service/network_service_jumbo_9.o
g++ -MMD -MF obj/services/network/network_service/network_service_jumbo_9.o.d -DIS_NETWORK_SERVICE_IMPL -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DOPENSSL_NO_ASM -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD -DUSING_SYSTEM_ICU=1 -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DUCHAR_TYPE=wchar_t -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 -DWEBRTC_CHROMIUM_BUILD -DWEBRTC_POSIX -DWEBRTC_OS2 -DWEBRTC_NO_INET6 -DABSL_ALLOCATOR_NOTHROW=1 -DWEBRTC_USE_BUILTIN_ISAC_FIX=0 -DWEBRTC_USE_BUILTIN_ISAC_FLOAT=1 -DHAVE_SCTP -DNO_MAIN_THREAD_WRAPPING -I. -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium -Igen -Igen -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/perfetto/include -Igen/third_party/perfetto/build_config -Igen/third_party/perfetto -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/libyuv/include -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/jsoncpp/source/include -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/jsoncpp/generated -Igen -Igen -Igen -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/boringssl/src/include -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src -Igen/protoc_out -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/ced/src -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/webrtc_overrides -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/webrtc -Igen/third_party/webrtc -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/abseil-cpp -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -Zomf -m32 -msse2 -mfpmath=sse -mmmx -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments -Wno-packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fomit-frame-pointer -s -I/@unixroot/usr/include/nss3 -I/@unixroot/usr/include/nspr4 -std=gnu++14 -Wno-narrowing -Wno-class-memaccess -Wno-attributes -Wno-class-memaccess -Wno-subobject-linkage -Wno-invalid-offsetof -Wno-return-type -Wno-deprecated-copy -fno-exceptions -fno-rtti -Wno-deprecated-declarations -c gen/services/network/network_service_jumbo_9.cc -o obj/services/network/network_service/network_service_jumbo_9.o
g++: internal compiler error: Segmentation fault signal terminated program cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://github.com/bitwiseworks/gcc-os2/issues> for instructions.
[5/5669] g++ -MMD -MF obj/services/network/network_service/network_service_jumbo_7.o.d -DIS_NETWORK_SERVICE_IMPL -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DOPENSSL_NO_ASM -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD -DUSING_SYSTEM_ICU=1 -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DUCHAR_TYPE=wchar_t -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 -DWEBRTC_CHROMIUM_BUILD -DWEBRTC_POSIX -DWEBRTC_OS2 -DWEBRTC_NO_INET6 -DABSL_ALLOCATOR_NOTHROW=1 -DWEBRTC_USE_BUILTIN_ISAC_FIX=0 -DWEBRTC_USE_BUILTIN_ISAC_FLOAT=1 -DHAVE_SCTP -DNO_MAIN_THREAD_WRAPPING -I. -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium -Igen -Igen -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/perfetto/include -Igen/third_party/perfetto/build_config -Igen/third_party/perfetto -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/libyuv/include -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/jsoncpp/source/include -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/jsoncpp/generated -Igen -Igen -Igen -Igen -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/boringssl/src/include -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src -Igen/protoc_out -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/protobuf/src -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/ced/src -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/webrtc_overrides -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/webrtc -Igen/third_party/webrtc -I../../../../../qt5-os2/qtwebengine/src/3rdparty/chromium/third_party/abseil-cpp -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -Zomf -m32 -msse2 -mfpmath=sse -mmmx -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments -Wno-packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fomit-frame-pointer -s -I/@unixroot/usr/include/nss3 -I/@unixroot/usr/include/nspr4 -std=gnu++14 -Wno-narrowing -Wno-class-memaccess -Wno-attributes -Wno-class-memaccess -Wno-subobject-linkage -Wno-invalid-offsetof -Wno-return-type -Wno-deprecated-copy -fno-exceptions -fno-rtti -Wno-deprecated-declarations -c gen/services/network/network_service_jumbo_7.cc -o obj/services/network/network_service/network_service_jumbo_7.o
ninja: build stopped: subcommand failed.
make[5]: *** [run_ninja] Error 1
make[5]: Leaving directory `C:/qt5-dev/qtwebengine/src/core'
make[4]: *** [release] Error 2
make[4]: Leaving directory `C:/qt5-dev/qtwebengine/src/core'
make[3]: *** [sub-gn_run-pro-release] Error 2
make[3]: Leaving directory `C:/qt5-dev/qtwebengine/src/core'
make[2]: *** [sub-core-release] Error 2
make[2]: Leaving directory `C:/qt5-dev/qtwebengine/src'
make[1]: *** [sub-src-release] Error 2
make[1]: Leaving directory `C:/qt5-dev/qtwebengine'
make: *** [module-qtwebengine-release] Error 2
Im afraid that's because OS2 sees only 1MB of mem on this machine.
Also a exceptq log in var about CC1PLUS


 
Title: Re: Building Qt5
Post by: Dave Yeo on October 25, 2022, 01:50:19 am
Im afraid that's because OS2 sees only 1MB of mem on this machine.
Also a exceptq log in var about CC1PLUS

The crash happens when configure  tests for precompiled header support, expected.
I take it you mean 1GB of ram. You still have the swap file. When I was building earlier versions of Firefox, around 10 IIRC, needed VIRTUALADDRESSLIMIT=3072 or linking xul.dll would gracefully die with an out of spill memory error. Then I had a simm die leaving me with 1.5 GBs of memory, I could still compile as long as not much else was running but if something like SM was running, the system would die with a swap file full error. There was lots of room for the swap file, but it is limited to 2GB.
Basically without enough ram, it should gracefully die rather then issue weird errors. A long time back I had a 486, OS/2 was trapping all the time so I moved to Linux, which at the time meant recompiling the kernel for your hardware, as no module support. Took a week as it kept dying with bus errors when trying to compile the kernel. Eventually discovered the computer had a broken 16 bit DMA thingy and things were stable if I didn't use 16 bit DMA. Just an example of broken hardware screwing up compilation.
Currently here, I'm still having problems with detecting libvpx and even after hacking qt5\qt5\webengine\src\buildtools\configure.json to detect libvpx, it died in webrtc trying to compile the intree libvpx.
I also get hard lockups, perhaps caused by my Snap system having to high of a VIRTUALADDRESSLIMIT. I think I'll wait for the next beta, do a new install and retry then.
Title: Re: Building Qt5
Post by: Paul Smedley on October 28, 2022, 12:15:07 am
I don't know why, but my build is dying with:
Code: [Select]
cd sqldrivers/ && ( test -e Makefile || U:/dev/qt5-dev-build/qtbase/bin/qmake.exe -o Makefile U:/dev/qt5/qtbase/src/plugins/sqldrivers/sqldrivers.pro ) && C:/USR/BIN/make.exe -f Makefile
Project ERROR: Could not find feature sql-psql.
make.exe[3]: *** [sub-sqldrivers-make_first] Error 3

Has anyone else seen this? I don't have postgresql installed in this box, but I would think it should be trying to detect it?

Further to this, grepping for sql-psql shows it should be disabled...

Code: [Select]
./qtbase/src/plugins/sqldrivers/qtsqldrivers-config.pri:QT.sqldrivers_private.disabled_features = sql-db2 sql-ibase sql-mysql sql-oci sql-odbc sql-psql sql-sqli
te2 sql-tds
Title: Re: Building Qt5
Post by: Dave Yeo on October 28, 2022, 06:28:36 am
I have K:/work/qt5/qt5-dev-build/qtbase/plugins/sqldrivers/qsqlite.dll so I guess your problem didn't happen here.
I moved to a different install and now libvpx also gets correctly found, eventually the system trapped with a processing error, so now trying with make -j1
Title: Re: Building Qt5
Post by: Paul Smedley on October 28, 2022, 08:20:14 am
Hi Dave,
I have K:/work/qt5/qt5-dev-build/qtbase/plugins/sqldrivers/qsqlite.dll so I guess your problem didn't happen here.

Yeah I got this too - the error was after this got built :(

Cheers,

Paul
Title: Re: Building Qt5
Post by: TeLLie on October 28, 2022, 05:52:37 pm
Hi Paul,

I dont see this error on my build..

I have in .pri file...

QT.sqldrivers.enabled_features =
QT.sqldrivers.disabled_features =
QT.sqldrivers.QT_CONFIG =
QT.sqldrivers.exports =
QT.sqldrivers_private.enabled_features = sql-sqlite system-sqlite
QT.sqldrivers_private.disabled_features = sql-db2 sql-ibase sql-mysql sql-oci sql-odbc sql-psql sql-sqlite2 sql-tds
QT.sqldrivers_private.libraries = sqlite
QMAKE_LIBS_SQLITE = -lsqlite3
QMAKE_DEPENDS_SQLITE_CC = ZLIB
QMAKE_DEPENDS_SQLITE_LD = ZLIB
Title: Re: Building Qt5
Post by: Dave Yeo on October 29, 2022, 03:26:26 am
Well, I'm still building without that error. A couple of times the system has popped up with a sys(something), not enough memory to process this command, make.exe and make (I think actually G++) froze forcing a reboot with the rest of the system stable. After stripping startup command, it continues compiling blink.
With 4 GB of memory installed, my swap file has grown to 72 MB's. First time I've seen it grow since the days with 2GB of ram. We're really at the limit of 32bit hardware.
Edit: sys0147, IIRC. Swap grew to 440MB before the popup, should have closed SeaMonkey quicker :) but other then the hung build VIO window system is stable. The memory widget says I'm using 2.9GB's of ram with 363 MB free and the 440MB swapper
Help 147 does helpfully make some suggestions,
Code: [Select]
o  Reduce the number of running programs.
o  Reduce the value of the BUFFERS=, TRACEBUF=, DISKCACHE=, THREADS=,
   RMSIZE=, or DEVICE=VDISK.SYS statement in the CONFIG.SYS file and
   restart the system.
Title: Re: Building Qt5
Post by: David McKenna on October 29, 2022, 03:39:28 pm
 I wonder if - on an OS/2 system used for compiling programs - eliminating DOS/Win support and running PROTECTONLY=YES would make any sense? Might free up some memory and even speed it up. Or does the compilation require DOS/Win support?
Title: Re: Building Qt5
Post by: Dave Yeo on October 29, 2022, 06:04:02 pm
I'll try with PROTECTONLY=YES, which IIRC, will by itself stop all the mdos/winos2 stuff loading. The build died this time with,
Code: [Select]
cc1plus.exe: out of memory allocating 65536 bytes after a total of 65536 bytesThis is getting quite frustrating, must have spent over 24 hours of actual compiling, though with the hangs etc it is hard to judge, obj directory is now 2GB, and this is a rel build, a debug probably would use more memory, but maybe not if less optimized.
It is hard to imagine doing much developing on the code if it takes a day to recompile and as this is my usual use machine, it also means not using it while compiling due to the tight memory. Of course this machine is a dozen years old so a newer fast machine would help. Still would be the memory problem and the way things go, the next update to the code is likely to use more memory.
The future does not look bright
Title: Re: Building Qt5
Post by: Dave Yeo on October 30, 2022, 06:19:06 pm
After adding the last prerequisites, removing the configure stuff to force a reconfiguration, setting PROTOCTONLY=YES, the build (release) succeeded, took 12+ hours. Haven't tested yet besides installing in my TMP, which is on my ramdisk.
Seems I only have 3.2 GB of ram accessible to the system, which might have been part of the reason for the swap file growth.
Title: Re: Building Qt5
Post by: Dave Yeo on October 30, 2022, 06:36:50 pm
Tesing, the Simplebrowser and Dooble both work and seem faster. Posting from Dooble.
Title: Re: Building Qt5
Post by: ivan on October 30, 2022, 07:13:34 pm
Hi Dave,

A quick question if I may.  Which of the thirty odd packages does one need to have a runtime like we have for Qt4?  Is it even possible?


Title: Re: Building Qt5
Post by: Dave Yeo on October 30, 2022, 07:37:13 pm
Hi Dave,

A quick question if I may.  Which of the thirty odd packages does one need to have a runtime like we have for Qt4?  Is it even possible?

No idea, but between QT5 needed libraries and dependencies, I can't see it being easy. It is why I gave up the fight some time back and started using Yum and/or ANPM to simply install this stuff.
Title: Re: Building Qt5
Post by: David McKenna on October 30, 2022, 09:25:18 pm
 Wow... congratulations Dave! Will you be posting the results?

Regards,
Title: Re: Building Qt5
Post by: Dave Yeo on October 30, 2022, 11:00:20 pm
Wow... congratulations Dave! Will you be posting the results?

Regards,

Hadn't really planned to, the uncompressed installed tree is 363MB, or 87MB 7z and the DLL's are 214 MB.
Also as it installed in h:\tmp\qt5, not sure how portable it is. Hmm grepping for h:/tmp/qt5, only qmake and the pc files (used to find stuff like libraries when developing/building) seem to have the PATH hardcoded
Guess if someone wants it, I could upload to Google drive or such, suggestions welcome.
Title: Re: Building Qt5
Post by: Roderick Klein on October 30, 2022, 11:27:49 pm
Im afraid that's because OS2 sees only 1MB of mem on this machine.
Also a exceptq log in var about CC1PLUS

The crash happens when configure  tests for precompiled header support, expected.
I take it you mean 1GB of ram. You still have the swap file. When I was building earlier versions of Firefox, around 10 IIRC, needed VIRTUALADDRESSLIMIT=3072 or linking xul.dll would gracefully die with an out of spill memory error. Then I had a simm die leaving me with 1.5 GBs of memory, I could still compile as long as not much else was running but if something like SM was running, the system would die with a swap file full error. There was lots of room for the swap file, but it is limited to 2GB.
Basically without enough ram, it should gracefully die rather then issue weird errors. A long time back I had a 486, OS/2 was trapping all the time so I moved to Linux, which at the time meant recompiling the kernel for your hardware, as no module support. Took a week as it kept dying with bus errors when trying to compile the kernel. Eventually discovered the computer had a broken 16 bit DMA thingy and things were stable if I didn't use 16 bit DMA. Just an example of broken hardware screwing up compilation.
Currently here, I'm still having problems with detecting libvpx and even after hacking qt5\qt5\webengine\src\buildtools\configure.json to detect libvpx, it died in webrtc trying to compile the intree libvpx.
I also get hard lockups, perhaps caused by my Snap system having to high of a VIRTUALADDRESSLIMIT. I think I'll wait for the next beta, do a new install and retry then.


I have seen this occur with SNAP loaded on some systems where setting the virtualaddresslimit to high can cause the system to lockup.
I have however NEVER seen this happen with Panorama loaded.



Roderick
Title: Re: Building Qt5
Post by: Dave Yeo on October 30, 2022, 11:47:26 pm
Yes, I was having the hard lockups on a Snap install. I rearranged things to have enough room on a Panorama install, lots of out of memory errors leaving the system stable, though often the VIO window locked up, so needing a reboot. Once the system locked up on the Panorama install.
Title: Re: Building Qt5
Post by: Roderick Klein on October 30, 2022, 11:58:29 pm
I'll try with PROTECTONLY=YES, which IIRC, will by itself stop all the mdos/winos2 stuff loading. The build died this time with,
Code: [Select]
cc1plus.exe: out of memory allocating 65536 bytes after a total of 65536 bytesThis is getting quite frustrating, must have spent over 24 hours of actual compiling, though with the hangs etc it is hard to judge, obj directory is now 2GB, and this is a rel build, a debug probably would use more memory, but maybe not if less optimized.
It is hard to imagine doing much developing on the code if it takes a day to recompile and as this is my usual use machine, it also means not using it while compiling due to the tight memory. Of course this machine is a dozen years old so a newer fast machine would help. Still would be the memory problem and the way things go, the next update to the code is likely to use more memory.
The future does not look bright

While your conclusion about the future not looking because of the issue you encountered  compiling the webkit DLL,  based on the results, is logical. I would hwoever like to suggest to be more reserved drawing that conclusion the "future not looking bright". Its again a lack of time we are having as community. The issue you encrountered is known but we have not looked into how to resolve this further.

So idea's exists how the we *migh*t be able to work around this issue. But this requires research. Nobody best I can tell ever did research why the system is running out of memory. I discussed the issue with Steve Levine months ago. I forgot what he had mentioned as options to look into.  Its month ago.
But I would not say we have hit the end of the track. No research has been done why the lockup occurs/what is the memory consumed by.

It might also be possible to drastically reduce the compile time on OS/2. But will require some changes in the compiler. Again I discussed this months ago. So I might have not worded this all properly.
On a MacOS box I think compiling the webkit DLL takes about 4 hours. So we can still improve this all.
But it needs to hit the top of the list.

I BTW wonder how much RAM protectonly=yes setting will give you back. Since you do not load any DOS or WINOS2 sessions I think the implact will be minimal....

Roderick
Title: Re: Building Qt5
Post by: Dave Yeo on October 31, 2022, 12:20:23 am
Well, I must say my last run, which was successful, gave me much more hope.
One trick that would help a lot would be to port ccache, https://ccache.dev/ (https://ccache.dev/). It is a compiler cache so a second run of the same build would be way faster and memory efficient. Likewise if only one file is changed, make might rebuild most everything, with ccache, only the changed file and dependent files would be rebuilt, once again resulting in a huge speedup.
As for memory used, interestingly OS/2 seemed to be better then other 32 bit systems at compiling Mozilla, at least memory wise. The *nixes are much faster at forking etc new processes, which happens a lot when compiling, while we're faster then Windows.
Title: Re: Building Qt5
Post by: Paul Smedley on October 31, 2022, 09:30:47 am
After adding the last prerequisites, removing the configure stuff to force a reconfiguration, setting PROTOCTONLY=YES, the build (release) succeeded, took 12+ hours. Haven't tested yet besides installing in my TMP, which is on my ramdisk.
Seems I only have 3.2 GB of ram accessible to the system, which might have been part of the reason for the swap file growth.

Well done!! I need to work out why my build is dying in qtbase..... I might try installing those extra packages you mention..... can't hurt!!
Title: Re: Building Qt5
Post by: Paul Smedley on November 01, 2022, 09:12:29 am
@Dave,

Are you able to share your config.summary? Mine is attached. Might help me work out what's different for you.

Cheers,

Paul
Title: Re: Building Qt5
Post by: Dave Yeo on November 01, 2022, 03:20:05 pm
Sure, see I used the system pcre and also I only built a release build as previously I had problems building both. Also I have -no-dbus on my configure line.
Title: Re: Building Qt5
Post by: Paul Smedley on November 03, 2022, 09:51:12 am
Sure, see I used the system pcre and also I only built a release build as previously I had problems building both. Also I have -no-dbus on my configure line.

I think I give up.... I'm still getting this error ever after getting a config.summary almost identical to yours....
Title: Re: Building Qt5
Post by: Dave Yeo on November 03, 2022, 03:24:49 pm
Sure, see I used the system pcre and also I only built a release build as previously I had problems building both. Also I have -no-dbus on my configure line.

I think I give up.... I'm still getting this error ever after getting a config.summary almost identical to yours....

It's weird, I had the problem with not detecting libvpx, which only went away when I moved to a different install. I really can't see why it was failing, the headers are identical and Mozilla built fine using the system libvpx.
Guess you could nuke your Unixroot tree and start over.
I still have to test a debug build and a both build, just reluctant as it takes 12 hours+ and can't do anything else on the machine due to memory shortage.
Title: Re: Building Qt5
Post by: Mentore on November 04, 2022, 09:38:06 am
Sure, see I used the system pcre and also I only built a release build as previously I had problems building both. Also I have -no-dbus on my configure line.

I think I give up.... I'm still getting this error ever after getting a config.summary almost identical to yours....

It's weird, I had the problem with not detecting libvpx, which only went away when I moved to a different install. I really can't see why it was failing, the headers are identical and Mozilla built fine using the system libvpx.
Guess you could nuke your Unixroot tree and start over.
I still have to test a debug build and a both build, just reluctant as it takes 12 hours+ and can't do anything else on the machine due to memory shortage.

@Dave, @Paul, hope you'll give another try. I'm pretty much absent from the scene due to zero spare time, but still I'm keeping a close eye on what's happening to OS/2. Willing to work again on it ASAP, so I'll check on your progress. Keep up!

Mentore
Title: Re: Building Qt5
Post by: Paul Smedley on November 04, 2022, 09:59:12 am
Sure, see I used the system pcre and also I only built a release build as previously I had problems building both. Also I have -no-dbus on my configure line.

I think I give up.... I'm still getting this error ever after getting a config.summary almost identical to yours....

It's weird, I had the problem with not detecting libvpx, which only went away when I moved to a different install. I really can't see why it was failing, the headers are identical and Mozilla built fine using the system libvpx.
Guess you could nuke your Unixroot tree and start over.
I still have to test a debug build and a both build, just reluctant as it takes 12 hours+ and can't do anything else on the machine due to memory shortage.

I got past the sql-psql error by hacking sqldriver.pro - but then I die with:
Project ERROR: Project has no top-level .qmake.conf file.

<sigh>
Title: Re: Building Qt5
Post by: Dave Yeo on November 04, 2022, 05:41:05 pm
I wonder if our git handles submodules the best. I ended up at one point going through the tree and doing a "git checkout master" in every module, they were all in a detached state. Could always do a "git fsck" in every submodule too. The chromium submodule is hiding a few layers deep.
Title: Re: Building Qt5
Post by: Paul Smedley on November 04, 2022, 09:28:14 pm
Hey Dave,
I wonder if our git handles submodules the best. I ended up at one point going through the tree and doing a "git checkout master" in every module, they were all in a detached state. Could always do a "git fsck" in every submodule too. The chromium submodule is hiding a few layers deep.

Interesting..... https://github.com/bitwiseworks/qtbase-os2/blob/master/.qmake.conf absolutely exists, and is absolutley in my x:\dev\qt5\qtbase :( Is this the only copy of .qmake.conf you have in qtbase?
Title: Re: Building Qt5
Post by: Paul Smedley on November 04, 2022, 09:52:20 pm
I can get past this with:
[u:\dev\qt5\qtbase] copy .qmake.conf src\plugins\bearer\generic\.qmake.conf

But not sure why this is needed....

A few more .pro hacks and qtbase is built. I got some error about dbus not being found but I had configured with -no-dbus - it's like the top level config file isn't being read...
Title: Re: Building Qt5
Post by: Paul Smedley on November 06, 2022, 09:36:47 am
I can get past this with:
[u:\dev\qt5\qtbase] copy .qmake.conf src\plugins\bearer\generic\.qmake.conf

But not sure why this is needed....

A few more .pro hacks and qtbase is built. I got some error about dbus not being found but I had configured with -no-dbus - it's like the top level config file isn't being read...

Interesting... there's *something* missing on my baremetal rpm/yum build environment. I'm building in a VM using my bastardised/bespoke build system and using GCC 12.2.0 and getting much further. I need to try and work out what's different/missing on the baremetal install...
Title: Re: Building Qt5
Post by: Sigurd Fastenrath on November 06, 2022, 09:45:56 am
Hi Paul,

while we had our User Meeting in Cologne yesterday, we discussed about the New Browser and your work here as well. We could not figure out: do you do this in colaboration with bitwise? Do you sync your work with them, Silvan, Dimitry, Herwig, are you in contact with them?

The attendents collected 400 Euro yesterday, that will be sent to Bitwise supporting their work.

Thanks for some background information!
Title: Re: Building Qt5
Post by: Paul Smedley on November 06, 2022, 10:01:03 am
Hi Sigurd - I have little to no contact with Bitwise - other than occasionally with Dmitry via github.

I'm really just trying to built qt5 out of academic interest - and have been keeping dooble up to date as nobody else has been..

At the moment I have no patches for qt5, so have nothing to contribute, but I did submit a PR for an update to the dooble source code.
Title: Re: Building Qt5
Post by: Dave Yeo on November 06, 2022, 06:27:40 pm
Hi Paul, what does git branch say in each install and also git log.
Here, for qtbase, it is on the master branch and the head of git log is,
Code: [Select]
commit ecf56e2f004911b5c15cc68afa3a7ee05ada0d16
Author: Dmitriy Kuminov <coding@dmik.org>
Date:   Fri Nov 4 01:58:08 2022 +0300

    Update CHANGELOG for version 5.15.2 OS/2 Beta 2.

commit b037b745dd403030bdd8962016787730829a74e4
Author: Dmitriy Kuminov <coding@dmik.org>
Date:   Sun Oct 23 22:58:27 2022 +0300

    platforms/os2: Fix bogus mouse X coordinate translation.

    Due to a bug in OS/2 macros local window coordinates -1, -2 would become
    65565, 65534 etc. breaking e.g. the menubar functionality.

    Closes #122.

commit ae484a2e10b5febee3537b07437ad5da0707655a
Author: Dmitriy Kuminov <coding@dmik.org>
Date:   Tue Sep 21 23:32:31 2021 +0300

    Update CHANGELOG for version 5.15.2 OS/2 Beta 1.

commit 95e2fb0a629ea542428398a47129369f70154b99
Author: Dmitriy Kuminov <coding@dmik.org>
Date:   Tue Sep 14 00:26:08 2021 +0300

    Disable relocatable qmake binary on OS/2.

    This exposes a number of problems related to not supporting hard links
    (broken qmake prefixes in RPM builds) and install targets with
    INSTALL_ROOT override.

    Closes #132.

commit 359ae76b6c31d2690b6676d5450a2a8894a1de64
Author: Dmitriy Kuminov <coding@dmik.org>
Date:   Mon Sep 13 03:30:01 2021 +0300

    mkspecs/os2-g++: Don't force debug_and_release any more.

    For RPM builds we need to disable it completely because the RPM devel
    packages do not provide debug libraries and it simply makes no sense
    to create two Makefile flavors: the debug one will never work.

    Note that this commit also makes configure automatically append
    debug_and_release to CONFIG in qconfig.pri when the feature is
    auto-detected or explicitly enabled. Without this change it would
    have to be forced in order to take effect even when building Qt
   itself (looks like an upstream bug).
Title: Re: Building Qt5
Post by: Paul Smedley on November 06, 2022, 10:09:08 pm
Hey Dave,

Hi Paul, what does git branch say in each install and also git log.
Here, for qtbase, it is on the master branch and the head of git log is,
Code: [Select]
commit ecf56e2f004911b5c15cc68afa3a7ee05ada0d16
Author: Dmitriy Kuminov <coding@dmik.org>
Date:   Fri Nov 4 01:58:08 2022 +0300

    Update CHANGELOG for version 5.15.2 OS/2 Beta 2.

commit b037b745dd403030bdd8962016787730829a74e4
Author: Dmitriy Kuminov <coding@dmik.org>
Date:   Sun Oct 23 22:58:27 2022 +0300

    platforms/os2: Fix bogus mouse X coordinate translation.

    Due to a bug in OS/2 macros local window coordinates -1, -2 would become
    65565, 65534 etc. breaking e.g. the menubar functionality.

    Closes #122.

commit ae484a2e10b5febee3537b07437ad5da0707655a
Author: Dmitriy Kuminov <coding@dmik.org>
Date:   Tue Sep 21 23:32:31 2021 +0300

    Update CHANGELOG for version 5.15.2 OS/2 Beta 1.

commit 95e2fb0a629ea542428398a47129369f70154b99
Author: Dmitriy Kuminov <coding@dmik.org>
Date:   Tue Sep 14 00:26:08 2021 +0300

    Disable relocatable qmake binary on OS/2.

    This exposes a number of problems related to not supporting hard links
    (broken qmake prefixes in RPM builds) and install targets with
    INSTALL_ROOT override.

    Closes #132.

commit 359ae76b6c31d2690b6676d5450a2a8894a1de64
Author: Dmitriy Kuminov <coding@dmik.org>
Date:   Mon Sep 13 03:30:01 2021 +0300

    mkspecs/os2-g++: Don't force debug_and_release any more.

    For RPM builds we need to disable it completely because the RPM devel
    packages do not provide debug libraries and it simply makes no sense
    to create two Makefile flavors: the debug one will never work.

    Note that this commit also makes configure automatically append
    debug_and_release to CONFIG in qconfig.pri when the feature is
    auto-detected or explicitly enabled. Without this change it would
    have to be forced in order to take effect even when building Qt
   itself (looks like an upstream bug).

I'm becoming increasing convinced my problem is environment related. The problematic build is a new AOS 5.0.7 install, that has effectively never been used to build anything.

In the 1st instance, I'm trying to build with a vanilla rpm/yum setup - my thoughts are that there is some GNU tool or ENV setting missing.

Now that I know things work on my VM install of AOS with MY build environment, I'll try work out what's missing in the RPM/YUM environment.

At least now I have something working locally in order to compare against!

Cheers,

Paul.
Title: Re: Building Qt5
Post by: Dave Yeo on November 06, 2022, 11:21:44 pm
Some of my environment, mostly put there for Mozilla,
Code: [Select]
SET SHELL=sh.exe
SET EMXSHELL=sh.exe
SET CONFIG_SHELL=sh.exe
SET MAKESHELL=sh.exe
SET EXECSHELL=sh.exe
set LANG=en_US
set EMXOMFLD_TYPE=WLINK
set EMXOMFLD_LINKER=wl.exe DISA 121,58
REM w: is my unixroot
set PATH=w:\usr\libexec\bin;%PATH%

Also things like print.com in \OS2 moved out of the way


Title: Re: Building Qt5
Post by: Igor on November 22, 2022, 03:57:00 pm
Dear builders Qt5 please turn off the AVX (and AVX2) code. Due to its presence, the browser does not display the pages. And it is impossible to use libraries. I don’t understand why this code is included if it does not work on OS/2 correctly?
Title: Re: Building Qt5
Post by: Dave Yeo on November 22, 2022, 06:12:28 pm
Dear builders Qt5 please turn off the AVX (and AVX2) code. Due to its presence, the browser does not display the pages. And it is impossible to use libraries. I don’t understand why this code is included if it does not work on OS/2 correctly?

Hi Igor, the code does work correctly on OS/2, namely the kernel claims no AVX support so the instructions aren't used.
I take it you are using the OS/4 kernel and running into the issue that our GCC can't correctly align the AVX instructions. It is easy enough to turn them off by passing configure the arguments,
Code: [Select]
-no-avx -no-avx2 -no-avx512
if I read the output from configure --help correctly.
What you need to do is open an issue at Bitwise's Github QT4 project requesting they do it. I'd guess as it is so easy to do they will respond positively.
You should also mention it in the QT6 thread so Paul can add the above configure arguments.
Problem is building the whole QT5 stack is slow and memory intensive so how quick it will happen? I might try rebuilding the QT5 stack if I get the chance, it takes about 12 hours here and I can't do much while building otherwise I run out of memory.
Title: Re: Building Qt5
Post by: Roderick Klein on November 23, 2022, 12:00:07 am
Dear builders Qt5 please turn off the AVX (and AVX2) code. Due to its presence, the browser does not display the pages. And it is impossible to use libraries. I don’t understand why this code is included if it does not work on OS/2 correctly?

Please open a ticket for this at Github for this issue on the BWW page.

And on which websites does happen so it can be reproduced ?

Thanks,

Roderick Klein
OS/2 VOICE
Title: Re: Building Qt5
Post by: Andi B. on November 23, 2022, 08:03:49 am
Dave, if I understand it correct, the problem is our gcc. So it would be necessary to fix gcc not Qt. What you propose is a work around for a bug in our gcc which only exposes on OS/4 kernel. Correct?
Title: Re: Building Qt5
Post by: Lars on November 23, 2022, 09:53:13 am
It's a mix of problems.

1) The compiler needs to properly align data to be loaded into an XMM (SSE) or YMM (AVX) or ZMM (AVX512)  register (at least for performance reasons but some instructions will also lead to a trap if a memory operand does not align on a 16-byte boundary (for SSE), 32-byte boundary (AVX) or 64-byte boundary (AVX52)).

2) an OS needs to support SSE/AVX/AVX512 context save and restore when switching from one application to another.

Regarding 2) , OS/2, eCS and ArcaOS only support SSE context save (FXSAVE, FXRSTOR: 128 bit registers) but OS/4 also supports AVX/AVX512 context save (XSAVE,XRSTOR: 128 bit and 256 bit and 512 bit registers).

So, the safest thing is to never use AVX/AVX512. That will ensure that you can run your SW on OS/2, eCS, ArcaOS and also on OS/4.

If I am wrong, someone please correct me. Personally, I can say that SSE can safely be used (with memory operands 16-byte aligned where necessary) as I did so in the past and I am running eCS.
Title: Re: Building Qt5
Post by: OS4User on November 23, 2022, 01:39:01 pm
... OS/4 also supports AVX/AVX512...

OS/4 currently supports AVX only
Title: Re: Building Qt5
Post by: Dave Yeo on November 23, 2022, 05:51:55 pm
Dave, if I understand it correct, the problem is our gcc. So it would be necessary to fix gcc not Qt. What you propose is a work around for a bug in our gcc which only exposes on OS/4 kernel. Correct?

Basically correct. Lars's description is pretty good but to expand on his point one.
Our GCC compiles code into the aout object format. Aout is primitive and doesn't understand the .align directive, so the resulting machine language is randomly aligned (it might support .align 4, I forget) when it comes to SSE+ instructions. The fix is to change the object type, likely to ELF, a fairly big job that might never happen though it has been planned.
There is also an issue open for supporting AVX+ in the OS/2 kernel, might happen and might not as it means patching the kernel to store the registers during context switches. If this happens or the OS/4 kernel is used, these programs crash. Even if the kernel is updated along with GCC, we still have all the older code floating around that will crash. Disabling the use of AVX+ until GCC is fixed will prevent this in the future.
Title: Re: Building Qt5
Post by: OS4User on November 23, 2022, 06:32:59 pm
...store the registers during context switches. If this happens or the OS/4 kernel is used, these programs crash.

Small clarification.

Programs crash happens not because of "store the registers during context switches".
It happens because  programs detects AVX support by OS and thus uses AVX branches of  their code.

And as you rightly said, our set (GCC + linker) is not able to  generate correct AVX code. But there is hope.  :)
Title: Re: Building Qt5
Post by: Dariusz Piatkowski on November 24, 2022, 03:02:55 am
Small clarification.

Programs crash happens not because of "store the registers during context switches".
It happens because  programs detects AVX support by OS and thus uses AVX branches of  their code.

And as you rightly said, our set (GCC + linker) is not able to  generate correct AVX code. But there is hope.  :)

OK, the BOLD highlight is mine...and that's also the focus point: so enlighten us, what exactly does that mean? (is someone else working on getting the GCC thing fixed-up for us? I ask b/c AFAIK Paul is the only one who actively maintains and ports the latest releases...sooo....????)
Title: Re: Building Qt5
Post by: Dave Yeo on November 24, 2022, 03:38:41 am
Well, Bitwise has expressed interest in adding Elf support and Paul did some work on it. Turns out that wlink can produce OS/2 executables from ELF objects but has problems with C++ code, or rather symbols, and it is possible that Steven might find time to fix that.
Title: Re: Building Qt5
Post by: Paul Smedley on November 24, 2022, 05:33:08 am
Well, Bitwise has expressed interest in adding Elf support and Paul did some work on it. Turns out that wlink can produce OS/2 executables from ELF objects but has problems with C++ code, or rather symbols, and it is possible that Steven might find time to fix that.

Slight correction to the above.... GCC itself doesn't produce a.out or ELF code - it produces assembly; then gas (GNU Assessember) converts that assembler code into object code. It's trivial to compile gas.exe for OS/2 to use ELF format code; but as Dave says, the linker is the problem. wlink works for some cases, but not all.

Then the work would need to go into emxomfld and probably emxexp/emximp to handle things.....
Title: Re: Building Qt5
Post by: Lars on November 24, 2022, 02:56:36 pm
...store the registers during context switches. If this happens or the OS/4 kernel is used, these programs crash.

Small clarification.

Programs crash happens not because of "store the registers during context switches".
It happens because  programs detects AVX support by OS and thus uses AVX branches of  their code.

And as you rightly said, our set (GCC + linker) is not able to  generate correct AVX code. But there is hope.  :)

You are raising an interesting question:

I recently released a new USBWAV.DLL containing 2 IOProcs where it made sense to implement certain things with SIMD instructions (SSE ...).
I hand coded the SIMD code in assembly, using the NASM assembler which also allowed me to force alignment where necessary. But my code only checks if SSE/SSE2/SSE3/SSSE3 is supported by the CPU but it does not check for CR4.OSFXSR flag that indicates that the OS supports SSE context save/restore as I know that OS/2 supports that (for SSE).
Does other SIMD code explicitely check not only for CPU support but also OS support ? And since reading CR4 into a register is only available in Ring 0, so how would application SW (executing in Ring 3) be able to check for that flag ?

Lars
Title: Re: Building Qt5
Post by: Silvan Scherrer on November 24, 2022, 08:12:16 pm
Dear builders Qt5 please turn off the AVX (and AVX2) code. Due to its presence, the browser does not display the pages. And it is impossible to use libraries. I don’t understand why this code is included if it does not work on OS/2 correctly?

Please open a ticket for this at Github for this issue on the BWW page.

And on which websites does happen so it can be reproduced ?

Thanks,

Roderick Klein
OS/2 VOICE
no need to open a ticket, as we build with -mno-avx since about 15 month. so nothing which is newer should face the issue.
Title: Re: Building Qt5
Post by: Dave Yeo on November 25, 2022, 04:00:47 am

I hand coded the SIMD code in assembly, using the NASM assembler which also allowed me to force alignment where necessary. But my code only checks if SSE/SSE2/SSE3/SSSE3 is supported by the CPU but it does not check for CR4.OSFXSR flag that indicates that the OS supports SSE context save/restore as I know that OS/2 supports that (for SSE).
Does other SIMD code explicitely check not only for CPU support but also OS support ? And since reading CR4 into a register is only available in Ring 0, so how would application SW (executing in Ring 3) be able to check for that flag ?

Lars

Used to see some software that checked for OS SSE support, looking I can't find much besides things like this from flac's changelog, (1.2.0)
Code: [Select]
* flac:
    * Added runtime detection of SSE OS support for most operating systems.
Googling, I found this, https://github.com/0xdaryl/omr/commit/83d57d1d09bf13cc71f3f085d56e05cb476bc31f (https://github.com/0xdaryl/omr/commit/83d57d1d09bf13cc71f3f085d56e05cb476bc31f).
Remember that most versions of OS/2 did not support SSE so if someone installs your USBWAVE.DLL on Warp v4 or older, I assume it will crash.
Title: Re: Building Qt5
Post by: Lars on November 25, 2022, 03:07:32 pm

Used to see some software that checked for OS SSE support, looking I can't find much besides things like this from flac's changelog, (1.2.0)
Code: [Select]
* flac:
    * Added runtime detection of SSE OS support for most operating systems.
Googling, I found this, https://github.com/0xdaryl/omr/commit/83d57d1d09bf13cc71f3f085d56e05cb476bc31f (https://github.com/0xdaryl/omr/commit/83d57d1d09bf13cc71f3f085d56e05cb476bc31f).
Remember that most versions of OS/2 did not support SSE so if someone installs your USBWAVE.DLL on Warp v4 or older, I assume it will crash.

Possible. My hope would be that the most recent W4 kernels (10.104a and the AN kernel versions) will also support save/restore SSE state. After all, we're in 2022. But now that you are mentioning it, I have a partition that I can start with the W4 kernel. Let's see what happens.

Thanks for the link. They are taking a trick to check for OS support (checking for and catching (if necessary) an exception). Very instructive.
Title: Re: Building Qt5
Post by: Dave Yeo on November 25, 2022, 06:18:58 pm
The recent W4 kernels support SSE, what doesn't is the stock kernel installed with Warp V4 I believe. No idea which fixpak would need to be installed for SSE support.
Win95 never supported SSE either which was why programs needed to test. At this point most everything supports it. At that various OS's and even FF 53+ require a Pentium M or newer due to SSE2 requirements.
Title: Re: Building Qt5
Post by: OS4User on November 26, 2022, 07:29:41 am

Does other SIMD code explicitely check not only for CPU support but also OS support ? And since reading CR4 into a register is only available in Ring 0, so how would application SW (executing in Ring 3) be able to check for that flag ?


As I understand it, the R3 application should not check the support of SIMD by processor, but should check the support of  SAVE/RESTORE by OS.
Title: Re: Building Qt5
Post by: OS4User on November 26, 2022, 02:34:25 pm
Thanks for the link. They are taking a trick to check for OS support (checking for and catching (if necessary) an exception). Very instructive.

When CPUID executes with EAX set to 01H:

bit27  - OSXSAVE
A value of 1 indicates that the OS has set CR4.OSXSAVE[bit 18] to enable XSETBV/XGETBV instructions to access XCR0 and to support processor extended state management using XSAVE/XRSTOR. (https://www.felixcloutier.com/x86/cpuid)

May be that is a way  for  R3 application.
Title: Re: Building Qt5
Post by: Lars on November 26, 2022, 05:24:15 pm
You are right, that is the easiest and most straightforward way to detect OS support for AVX.
Unfortunately, there is nothing comparable to detect OS support for SSE (that is, CR4.OSFXSR being set instead of CR4.OSXSAVE being set). Looks like Intel never thinks any farther than up to the next corner.

Anyways. even for the later W4 kernels, OS support for SSE is in effect (I tried it and nothing crashed) and since we have 2022, that is sufficiently reliable information to build upon.
Title: Re: Building Qt5
Post by: OS4User on November 26, 2022, 05:45:02 pm
Anyways. even for the later W4 kernels, OS support for SSE is in effect (I tried it and nothing crashed) and since we have 2022, that is sufficiently reliable information to build upon.

Sure. You even can try to build AVX branch - since you have a good way to detect an OS support for it. ;)
Title: Re: Building Qt5
Post by: Lars on November 27, 2022, 12:24:46 pm
Anyways. even for the later W4 kernels, OS support for SSE is in effect (I tried it and nothing crashed) and since we have 2022, that is sufficiently reliable information to build upon.

Sure. You even can try to build AVX branch - since you have a good way to detect an OS support for it. ;)

Obviously, gcc supports automatic vectorization from C/C++ code but VAC and Watcom compilers do not. Since I never use gcc, I always have to hand code vectorization in assembler (which I do seldomly enough).
I don`t feel like handcoding a SSE version and a AVX version. The speedup with SSE for suitable core functions, compared to using general purpose registers, is already a factor of typically 16 (when using all 8 available XMM registers under 32-bit code) or even much higher, depending on data type (byte, word, dword, qword, single precision float, double precision float).