* use latest revision from chromium 87-based repo instead of the revision from submodule,
there are couple more security fixes:
$ git log --oneline e48df7803c7c98b0b2471c94057d32e44a301ad5..origin/87-based
fb66d7ca964 (origin/87-based) [Backport] CVE-2023-1530: Use after free in PDF (1/2)
7d80d640bf7 [Backport] CVE-2023-1531: Use after free in ANGLE
906ec4b3148 [Backport] Security bug 1418734
7acd92df98d [Backport] Security bug 1417585
d4dae0cad19 [Backport] Security bug 1337747
bfc3d37f279 [Backport] CVE-2023-1534: Out of bounds read in ANGLE
6514de99619 [Backport] CVE-2023-1529: Out of bounds memory access in WebHID
799ad56b699 [Backport] CVE-2023-1222: Heap buffer overflow in Web Audio API
9dd9b39ef9d [Backport] CVE-2023-1220: Heap buffer overflow in UMA
ca58730e230 [Backport] CVE-2023-1219: Heap buffer overflow in Metrics (3/3)
c1d9b7fd4fa [Backport] CVE-2023-1219: Heap buffer overflow in Metrics (2/3)
53d71ca32b1 [Backport] CVE-2023-1219: Heap buffer overflow in Metrics (1/3)
bf140f0d01b [Backport] CVE-2023-1217: Stack buffer overflow in Crash reporting
aec0b21eb33 [Backport] CVE-2023-1215: Type Confusion in CSS
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* there are few newer commits since the SRCREV used in this recipe
it might be useful if someone is still using this (I don't, so
I'll just fix the build failure with gcc-13 and cleanup the .patch files):
$ git log --oneline 10cd6a106..origin/5.212
ac8ebc6c3 (origin/5.212) Enable QML tests
5a99e5d4c Import QtWebKit commit 5d89eef9bc689abb59ef799b445c35b1e322b3f1
685ed792f Import QtWebKit commit 143b469188bde226d5e70cff5f01699b8a29d865
8967b4f87 Import QtWebKit commit 6faf5d547055321f0d518fe83766499cac5d8664
08eaf858c Import QtWebKit commit cf37bc44f798d3c5a26d17086ada92688b9bfe6d
412e257d0 Workaround for Windows Store python3.exe
e16357a52 Import QtWebKit commit f966d667c14ddcfe983f4a31fc80a1edbb6ada10
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Some components use also base name in NVD CVE database product:
| sqlite> select * from products where product like 'qtbase';
| CVE-2019-18281|qt|qtbase|5.11.0|>=|5.11.3|<=
| CVE-2019-18281|qt|qtbase|5.12.0|>=|5.12.5|<
| sqlite> select * from products where product like 'qtsvg';
| CVE-2021-45930|qt|qtsvg|5.0.0|>=|5.15.2|<=
| CVE-2021-45930|qt|qtsvg|6.0.0|>=|6.2.1|<=
When using runtime-llvm it links with libc++ for host pieces as well
e.g. gn, therefore its going to use the c++ runtime thats built with
libcxx-native/compiler-rt-native and it does provide static C++ runtime
It builds for rv64 now, therefore enable it
Signed-off-by: Khem Raj <raj.khem@gmail.com>
clang-16 will be defaulting to c++17 across C++ runtime as well, which
means auto_ptr is reported as error, make provisions to replace it
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* a lot of Pending, but don't follow this example for other layers
in this case I didn't want to spend more time on the patches because
whole meta-qt5 is dead-end and not worth spending more of my free time.
If you're interested in Qt switch to meta-qt6 which is still receiving
updates.
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Recently Mesa synced egl headers with khronos.
Until now eglplatform.h added the xlib headers as long as it
hasn't been explicitly disabled with EGL_NO_X11. Now its one step
closer to deprecating X11 and the headers are only included if
USE_X11 is set. If missing qtbase silently refuses to build the EGL_X11
Plugin.
This results e.g. in configure failure for qtwayland, if building
with xcomposite-egl PACKAGECONFIG:
ERROR: Feature 'xcomposite-egl' was enabled, but the pre-condition
'features.wayland-client && features.opengl && features.egl && features.xlib
&& libs.xcomposite && features.egl_x11' failed.
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Tests are build against the destination directory where qt module was
just installed. This causes extra files to be taken into source package
and adds references to the TMPDIR, which produces QA warnings from
buildpaths QA test. Use DEBUG_PREFIX_MAP to get rid of those paths.
Pick-to: 6.4 6.3 6.2
Task-number: QTBUG-105913
Change-Id: I01ed9261004410db307f2cd809a181377b734c9e
Reviewed-by: Ari Parkkila <ari.parkkila@qt.io>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Testlib adds references to the build and source directories to tests,
which causes warnings on buildpaths QA test. Remove those references.
Pick-to: 6.4 6.3 6.2
Task-number: QTBUG-105913
Change-Id: Ic63e72a0b11bef55876ef5ca40d0c1d753243004
Reviewed-by: Ari Parkkila <ari.parkkila@qt.io>
This qtwebengine GN patch already assigns AR correctly one line above
to '--ar \"$$which(ar)\"' , drop the newly added upstream AR assignment
as it triggers build failure:
"
[184/187] CXX tools/gn/target.o
[185/187] CXX tools/gn/visual_studio_writer.o
[186/187] AR gn_lib.a
[187/187] LINK gn
FAILED: gn
/build/tmp/hosttools/g++ -O3 -fdata-sections -ffunction-sections -Wl,--gc-sections -Wl,-strip-all -Wl,--as-needed -static-libstdc++ -pthread -o gn -Wl,--start-group tools/gn/gn_main.o base.a gn_lib.a -Wl,--end-group -ldl
/build/tmp/hosttools/ld: base.a: error adding symbols: archive has no index; run ranlib to add one
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
Project ERROR: GN build error!
make[2]: *** [Makefile:98: sub-gn-pro-make_first] Error 3
"
MJ: for GN(-native) build we don't want to respect QMAKE_AR, we want ar for
host architecture and use $$which(ar) (will will be similar to $$first(BUILD_AR)
with BUILD_AR from bitbake.conf)
MJ: Refresh other patches to apply on top of this change.
MJ: it's not reproducible with qemux86-64 (which I was using to test the last upgrade):
martin@jama /OE/build/oe-core/tmp-glibc/work $ ls -lah core2-64-oe-linux/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a cortexa15t2hf-neon-oe-linux-gnueabi/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a
-rw-r--r-- 1 martin martin 99K Aug 8 22:01 core2-64-oe-linux/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a
-rw-r--r-- 1 martin martin 3.3K Aug 8 21:10 cortexa15t2hf-neon-oe-linux-gnueabi/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a
martin@jama /OE/build/oe-core/tmp-glibc/work $ file core2-64-oe-linux/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a cortexa15t2hf-neon-oe-linux-gnueabi/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a
core2-64-oe-linux/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a: thin archive with 1168 symbol entries
cortexa15t2hf-neon-oe-linux-gnueabi/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a: thin archive with 1650553701 symbol entries
The issue is that gn build will use arm-oe-linux-gnueabi-gcc-ar from QMAKE_AR which is correct for
target libraries, but in this case it's used for native gn and arm-oe-linux-gnueabi-gcc-ar doesn't
support native x86_64 host (while x86_64-oe-linux-gcc-ar used in qemux86-64 builds was fine, because
the architecture is compatible):
qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release $ ninja -v gn 2>&1
[1/2] rm -f base.a && /OE/build/oe-core/tmp-glibc/work/cortexa15t2hf-neon-oe-linux-gnueabi/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc-ar rcsT base.a base/callback_internal.o base/command_line.o base/environment.o base/files/file.o base/files/file_enumerator.o base/files/file_path.o base/files/file_path_constants.o base/files/file_util.o base/files/scoped_file.o base/files/scoped_temp_dir.o base/json/json_parser.o base/json/json_reader.o base/json/json_writer.o base/json/string_escape.o base/logging.o base/md5.o base/memory/ref_counted.o base/memory/weak_ptr.o base/sha1.o base/strings/string_number_conversions.o base/strings/string_piece.o base/strings/string_split.o base/strings/string_util.o base/strings/string_util_constants.o base/strings/stringprintf.o base/strings/utf_string_conversion_utils.o base/strings/utf_string_conversions.o base/third_party/icu/icu_utf.o base/timer/elapsed_timer.o base/value_iterators.o base/values.o base/files/file_enumerator_posix.o base/files/file_posix.o base/files/file_util_posix.o base/posix/file_descriptor_shuffle.o base/posix/safe_strerror.o base/strings/string16.o
[2/2] /OE/build/oe-core/tmp-glibc/hosttools/g++ -O3 -fdata-sections -ffunction-sections -Wl,--gc-sections -Wl,-strip-all -Wl,--as-needed -static-libstdc++ -pthread -o gn -Wl,--start-group tools/gn/gn_main.o base.a gn_lib.a -Wl,--end-group -ldl
FAILED: gn
/OE/build/oe-core/tmp-glibc/hosttools/g++ -O3 -fdata-sections -ffunction-sections -Wl,--gc-sections -Wl,-strip-all -Wl,--as-needed -static-libstdc++ -pthread -o gn -Wl,--start-group tools/gn/gn_main.o base.a gn_lib.a -Wl,--end-group -ldl
/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: base.a: error adding symbols: archive has no index; run ranlib to add one
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
$ arm-oe-linux-gnueabi-gcc-ar --help | grep supported.targets
recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/../../libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/12.1.0/ar:
supported targets: elf32-littlearm elf32-littlearm-fdpic elf32-bigarm elf32-bigarm-fdpic elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex plugin
$ ar --help | grep supported.targets
ar:
supported targets: elf64-x86-64 elf32-i386 elf32-iamcu elf32-x86-64 pei-i386 pe-x86-64 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex plugin
It would be better to force gn build to respect
BUILD_AR = "${BUILD_PREFIX}ar"
instead of "$$which(ar)" here or better just using separate gn-native recipe like meta-browser does since:
c5ff301787
but meta-qt5 is dead-end and I don't care enough to fix this.
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
We need to also check for compiler along with runtime to apply this
patch so we dont accidentally add these options when using TOOLCHAIN =
"gcc"
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
A modified version of the patch was merged upstream which has been confirmed to be working with GCC12, so I expect it will work with clang too.
Qt6 support has been added as well.
Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
* sync with qtwebengine recipe
* replace
0002-Remove-the-GN-settings-done-for-clang-that-conflict-.patch
with whole set of chromium patches from qtwebengine where
recipes-qt/qt5/qtwebengine/chromium/0002-chromium-fix-build-with-clang.patch
should do the same
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* contains useful fix to resolve:
https://github.com/meta-qt5/meta-qt5/pull/475
qtwebengine-chromium $ git log --oneline caba2fcb0fe8a8d213c4c79d26da3bb88eee61c7..ecc2bb74f1f7140fc52650042299be18e826b27b
ecc2bb74f1f [Backport] CVE-2022-0796: Use after free in Media
a7a23ccc69e [Backport] Linux sandbox: ENOSYS for some statx syscalls
7857ff290ab FIXUP: Workaround MSVC2022 ICE in constexpr functions
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
MeeGo prefix was made optional by sending the adjusted patch upstream. By defining "no-module-prefix" it will now build without prefix.
Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
gcc12 has started to fail with same error like clang, perhaps this
should be upstreamed too
usr/include/QtDBus/qdbusargument.h:276:13: error: no match for 'operator>>' (operand types are 'const QDBusArgument' and 'RouteStructure')
| 276 | arg >> item;
| | ~~~~^~~~~~~
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Fixes many complaints in configure as:
| sh: line 1: pkg-config: command not found
Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
gcc12 has started failing with same error like clang
| ../../../recipe-sysroot/usr/include/QtTest/qtestcase.h:340:34: error:
invalid operands to binary expression ('const MImServerCommonOptions'
and 'const MImServerCommonOptions')
| return compare_helper(t1 == t2, "Compared values are not the same",
| ~~ ^ ~~
There do not keep it clang specific anymore
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
since compiler for ppc64 defines both ppc and ppc64 its better to
check for ppc64 first
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Its needed for xcb platform which means its not needed when x11 is not
in distro features, limit the scope of this dependency to x11
fixes non-x11 builds
Signed-off-by: Khem Raj <raj.khem@gmail.com>
* https://github.com/meta-qt5/meta-qt5/issues/455
* https://lists.qt-project.org/pipermail/development/2022-March/042262.html
qtbase/0021-qfloat16-Include-limits-header.patch partially resolved in upstream commit:
0afad46bb7 Fix build with GCC 11: include <limits>
qtbase/0022-fix_timezone_dst.patch resolved in upstream commits:
692c7e021f Fix QTzTimeZonePrivate::displayName()'s fallback
5f91ed1493 QTzTimeZonePrivate::init(): fix handling of empty ID
9f74724d84 Fix handling of Sunday in POSIX time-zone rules
qtsvg/CVE-2021-3481.patch: partially resolved in upstream commit:
aceea78 Improve handling of malformed numeric values in svg files
but the 2nd part is still needed.
qtcoap, qtknx, qtmqtt, qtopcua: keep QT_MODULE_BRANCH "5.15.2" as
it still wasn't downmerged to 5.15 branch and there is no
v5.15.3-lts-lgpl tag in these as well
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
OE clang add -target option itself, there is no need to detect it in
Chromium GN time
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
use GNU runtime when building native tools like gn
when using native clang compiler
Fixes
| FAILED: gn
| /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux/qtpdf/5.15.8+gitAUTOINC+73e76f9e86_48a205f9e0-r0/recipe-sysroot-native/usr/bin/clang++ -O3 -fdata-sections -ffunction-sections -Wl,--gc-sections -Wl,-stri
p-all -Wl,--as-needed -pthread -o gn -Wl,--start-group tools/gn/gn_main.o base.a gn_lib.a -Wl,--end-group -ldl
| /mnt/b/yoe/master/build/tmp/hosttools/ld: cannot find /usr/lib/clang/14.0.0/lib/linux/libclang_rt.builtins-x86_64.a: No such file or directory
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
