meta-browser icon indicating copy to clipboard operation
meta-browser copied to clipboard

Published 20 hours ago • verified publisher icon OSSystems

chromium: Update to 123.0.6312.122

Open MaxIhlenfeldt opened this issue 9 months ago • 2 comments

Fixes #796.

Note that this PR drops support for Nanbield (which is scheduled to reach its EOL this month anyway), see the discussion at #796 for why.

Release notes: https://chromereleases.googleblog.com/2024/03/stable-channel-update-for-desktop_19.html https://chromereleases.googleblog.com/2024/03/stable-channel-update-for-desktop_26.html https://chromereleases.googleblog.com/2024/04/stable-channel-update-for-desktop.html https://chromereleases.googleblog.com/2024/04/stable-channel-update-for-desktop_10.html

Build and patch changes:

Drop one backported patch that is included upstream now.

Rebase remaining patches.

License changes:

Added licenses:

  • third_party/android_deps/libs/com_google_android_gms_play_services_tflite_impl/LICENSE, third_party/android_deps/libs/com_google_android_gms_play_services_tflite_java/LICENSE, third_party/android_deps/libs/org_tensorflow_tensorflow_lite_api/LICENSE
  • https://chromium-review.googlesource.com/c/chromium/src/+/5288046
  • third_party/android_deps/libs/org_jetbrains_kotlin_kotlin_android_extensions_runtime/LICENSE, third_party/android_deps/libs/org_jetbrains_kotlin_kotlin_parcelize_runtime/LICENSE
  • https://chromium-review.googlesource.com/c/chromium/src/+/5260026
  • third_party/android_deps/libs/org_jetbrains_kotlinx_atomicfu_jvm/LICENSE
  • https://chromium-review.googlesource.com/c/chromium/src/+/5237443

Removed licenses:

  • third_party/catapult/third_party/Paste/docs/license.txt
  • https://chromium-review.googlesource.com/c/catapult/+/5288589
  • third_party/screen-ai/LICENSE
  • Not sure why.

Updated licenses:

  • third_party/android_deps/libs/com_google_android_gms_play_services_base/LICENSE
  • https://chromium-review.googlesource.com/c/chromium/src/+/5288046

Test-built (big thanks to @rjanani-p):

  • chromium-ozone-wayland:
  • master, clang, MACHINE=qemux86-64, raspberrypi4-64
  • chromium-x11:
  • master, clang, MACHINE=qemuarm, qemuarm64, qemux86-64

MaxIhlenfeldt avatar May 07 '24 16:05 MaxIhlenfeldt

@rjanani-p as always, testing would be greatly appreciated! Please note that the build for nanbield will not work, you only need to test scarthgap and master.

MaxIhlenfeldt avatar May 07 '24 16:05 MaxIhlenfeldt

Also, https://github.com/OSSystems/meta-browser/issues/792#issuecomment-2098781762 applies here as well: you'll probably need #808 as well to build master.

MaxIhlenfeldt avatar May 07 '24 16:05 MaxIhlenfeldt

Rebased this PR to include all the recently merged PRs. This should fix all build issues that are unrelated to this update.

@rjanani-p please let me know if there's anything else blocking you from testing this PR.

MaxIhlenfeldt avatar May 13 '24 11:05 MaxIhlenfeldt

@rjanani-p as always, testing would be greatly appreciated! Please note that the build for nanbield will not work, you only need to test scarthgap and master.

sure @MaxIhlenfeldt , I will start testing and update the test results. Thank you.

rjanani-p avatar May 14 '24 05:05 rjanani-p

@rjanani-p as always, testing would be greatly appreciated! Please note that the build for nanbield will not work, you only need to test scarthgap and master.

@MaxIhlenfeldt , I have completed the testing for Poky master with latest changes, sharing the results for reference:

1.For chromium-x11 & qemux86-64 target: compiled successfully without build issues, able to check chromium version using qemux86-64 emulator

2.For chromium-x11 & qemuarm target: compiled successfully without build issues, to check chromium version using qemuarm emulator unable to check it due to curser / mouse is not working properly while operating with chromium browser

3.For chromium-x11 & qemuarm64 target: compiled successfully without build issues, able to check chromium version using qemuarm64 emulator

4.For chromium-x11 & raspberrypi4-64 target: compiled successfully without build issues, didn't check with hardware due to hardware unavailability. 5. For chromium-ozone-wayland & qemux86-64 target: compiled successfully without build issues, able to check chromium version using qemux86-64 emulator

I will start testing for Poky scarthgap.

rjanani-p avatar May 16 '24 02:05 rjanani-p

@MaxIhlenfeldt , getting below build issue for poky_scarthgap branch for qemux86-64 target, could you please check once .

[237/58295] python3 ../../third_party/blink/renderer/build/scripts/run_with_pythonpath.py -I ../../third_party/blink/renderer/build/scripts -I ../../third_party -I ../../third_party/pyjson5/src -I ../../tools ../../third_party/blink/renderer/build/scripts/core/css/make_css_property_names.py ../../third_party/blink/renderer/core/css/css_properties.json5 ../../third_party/blink/renderer/core/css/computed_style_field_aliases.json5 ../../third_party/blink/renderer/platform/runtime_enabled_features.json5 --output_dir gen/third_party/blink/renderer/core/css --gperf gperf ninja: build stopped: subcommand failed. WARNING: $/builds_chromium/build_poky_scarthgap_chrom_123_ver/tmp/work/core2-64-poky-linux/chromium-x11/123.0.6312.122/temp/run.do_compile.1636856:149 exit 1 from 'ninja -v -j 64 chrome chrome_sandbox chromedriver.unstripped' WARNING: Backtrace (BB generated script): $ builds_chromium/build_poky_scarthgap_chrom_123_ver/tmp/work/core2-64-poky-linux/chromium-x11/123.0.6312.122/temp/run.do_compile.1636856, line 149

line 149 contains, below code snippet: meta-browser/meta-chromium/recipes-browser/chromium/chromium-gn.inc do_compile() { export CRATE_CC_NO_DEFAULTS=1 ninja -v -j 64 chrome chrome_sandbox chromedriver.unstripped }

$ builds_chromium/build_poky_scarthgap_chrom_123_ver/tmp/work/core2-64-poky-linux/chromium-x11/123.0.6312.122/temp/run.do_compile.1636856, line 153

Please find build log error:

[174/58295] python3 ../../third_party/node/node.py ../../third_party/devtools-frontend/src/front_end/core/i18n/collect-ui-strings.js --input-directories ../../third_party/devtools-frontend/src/front_end --output-directory gen/third_party/devtools-frontend/src/front_end/core/i18n/locales/generated
FAILED: gen/third_party/devtools-frontend/src/front_end/core/i18n/locales/generated/en-US.json
python3 ../../third_party/node/node.py ../../third_party/devtools-frontend/src/front_end/core/i18n/collect-ui-strings.js --input-directories ../../third_party/devtools-frontend/src/front_end --output-directory gen/third_party/devtools-frontend/src/front_end/core/i18n/locales/generated
Traceback (most recent call last):
  File "$/builds_chromium/build_poky_scarthgap_chrom_123_ver/tmp/work/core2-64-poky-linux/chromium-x11/123.0.6312.122/chromium-123.0.6312.122/out/Release/../../third_party/node/node.py", line 39, in <module>
    RunNode(sys.argv[1:])
  File "$/builds_chromium/build_poky_scarthgap_chrom_123_ver/tmp/work/core2-64-poky-linux/chromium-x11/123.0.6312.122/chromium-123.0.6312.122/out/Release/../../third_party/node/node.py", line 34, in RunNode
    raise RuntimeError('Command \'%s\' failed\n%s' % (' '.join(cmd), err))
RuntimeError: Command '$/builds_chromium/build_poky_scarthgap_chrom_123_ver/tmp/work/core2-64-poky-linux/chromium-x11/123.0.6312.122/chromium-123.0.6312.122/out/Release/../../third_party/node/linux/node-linux-x64/bin/node ../../third_party/devtools-frontend/src/front_end/core/i18n/collect-ui-strings.js --input-directories ../../third_party/devtools-frontend/src/front_end --output-directory gen/third_party/devtools-frontend/src/front_end/core/i18n/locales/generated' failed
$/builds_chromium/build_poky_scarthgap_chrom_123_ver/tmp/work/core2-64-poky-linux/chromium-x11/123.0.6312.122/chromium-123.0.6312.122/third_party/devtools-frontend/src/node_modules/glob/common.js:19
  return a.localeCompare(b, 'en')
           ^

RangeError: Internal error. Icu error.
    at String.localeCompare (<anonymous>)
    at alphasort ($/builds_chromium/build_poky_scarthgap_chrom_123_ver/tmp/work/core2-64-poky-linux/chromium-x11/123.0.6312.122/chromium-123.0.6312.122/third_party/devtools-frontend/src/node_modules/glob/common.js:19:12)

 at Array.sort (<anonymous>)
    at Object.finish ($/builds_chromium/build_poky_scarthgap_chrom_123_ver/tmp/work/core2-64-poky-linux/chromium-x11/123.0.6312.122/chromium-123.0.6312.122/third_party/devtools-frontend/src/node_modules/glob/common.js:147:15)
    at GlobSync._finish ($/builds_chromium/build_poky_scarthgap_chrom_123_ver/tmp/work/core2-64-poky-linux/chromium-x11/123.0.6312.122/chromium-123.0.6312.122/third_party/devtools-frontend/src/node_modules/glob/sync.js:71:10)
    at new GlobSync ($/builds_chromium/build_poky_scarthgap_chrom_123_ver/tmp/work/core2-64-poky-linux/chromium-x11/123.0.6312.122/chromium-123.0.6312.122/third_party/devtools-frontend/src/node_modules/glob/sync.js:48:8)
    at Function.globSync [as sync] ($/builds_chromium/build_poky_scarthgap_chrom_123_ver/tmp/work/core2-64-poky-linux/chromium-x11/123.0.6312.122/chromium-123.0.6312.122/third_party/devtools-frontend/src/node_modules/glob/sync.js:24:10)
    at collectAllStringsInDir ($/builds_chromium/build_poky_scarthgap_chrom_123_ver/tmp/work/core2-64-poky-linux/chromium-x11/123.0.6312.122/chromium-123.0.6312.122/third_party/devtools-frontend/src/third_party/i18n/collect-strings.js:606:22)
    at Object.<anonymous> ($/builds_chromium/build_poky_scarthgap_chrom_123_ver/tmp/work/core2-64-poky-linux/chromium-x11/123.0.6312.122/chromium-123.0.6312.122/third_party/devtools-frontend/src/front_end/core/i18n/collect-ui-strings.js:61:8)
    at Module._compile (node:internal/modules/cjs/loader:1369:14)

Node.js v20.12.2

rjanani-p avatar May 17 '24 08:05 rjanani-p

@MaxIhlenfeldt , getting below build issue for poky_scarthgap branch for qemux86-64 target, could you please check once .

Hm, this seems to be the same error you described in https://github.com/OSSystems/meta-browser/pull/803#issuecomment-2031860810. If I understand https://github.com/OSSystems/meta-browser/pull/803#issuecomment-2048959001 correctly, that time the issue didn't happen any more in a clean build. Can you please try doing a clean build and see if it fixes the issue this time as well?

MaxIhlenfeldt avatar May 17 '24 13:05 MaxIhlenfeldt

@MaxIhlenfeldt , getting below build issue for poky_scarthgap branch for qemux86-64 target, could you please check once .

Hm, this seems to be the same error you described in #803 (comment). If I understand #803 (comment) correctly, that time the issue didn't happen any more in a clean build. Can you please try doing a clean build and see if it fixes the issue this time as well?

@MaxIhlenfeldt ,I have tried with clean build, but getting same issue. Did you observe same issue during you are testing.

rjanani-p avatar May 18 '24 13:05 rjanani-p

@MaxIhlenfeldt ,I have tried with clean build, but getting same issue. Did you observe same issue during you are testing.

@rjanani-p I haven't seen this specific error message in any local build I've done. As the error is related to Node's internationalization support, please provide the following information that hopefully helps with finding its cause. (reference: https://nodejs.org/api/intl.html)

Node build setup

The default for the nodejs recipe is to build Node with the --with-intl=system-icu option. Can you please check that this is the case for your build by running bitbake -e nodejs-native | grep -B 25 PACKAGECONFIG= and pasting the output here? For my build, the output is this:

# pre-expansion value:
#   "${PN}-${PV}"
P="nodejs-native-20.12.2"
#
# $PACKAGECONFIG [9 operations]
#   set /home/chromium/yocto-chromium/sources/poky/meta/conf/documentation.conf:321
#     [doc] "This variable provides a means of enabling or disabling features of a recipe on a per-recipe basis."
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:67
#     [_defaultval] "ares brotli icu zlib"
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:69
#     [ares] "--shared-cares,,c-ares"
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:70
#     [brotli] "--shared-brotli,,brotli"
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:71
#     [icu] "--with-intl=system-icu,--without-intl,icu"
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:72
#     [libuv] "--shared-libuv,,libuv"
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:73
#     [nghttp2] "--shared-nghttp2,,nghttp2"
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:74
#     [shared] "--shared"
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:75
#     [zlib] "--shared-zlib,,zlib"
# pre-expansion value:
#   "ares brotli icu zlib"
PACKAGECONFIG="ares brotli icu zlib"

And to be completely sure, please run bitbake -c devshell nodejs-native and in that shell run grep -A 15 'do_configure()' ../temp/run.do_configure and paste the output here. For my build, the output is this:

do_configure() {
    GYP_DEFINES="${GYP_DEFINES}" export GYP_DEFINES
    # $TARGET_ARCH settings don't match --dest-cpu settings
    python3 configure.py --verbose --prefix=/home/chromium/yocto-chromium/builds/chromium-x11-qemux86-64-scarthgap/tmp-glibc/work/x86_64-linux/nodejs-native/20.12.2/recipe-sysroot-native/usr \
               --shared-openssl \
               --dest-cpu="x64" \
               --dest-os=linux \
               --libdir=lib \
               --no-cross-compiling \
                \
                --shared-cares --shared-brotli --with-intl=system-icu --shared-zlib
}

cd '/home/chromium/yocto-chromium/builds/chromium-x11-qemux86-64-scarthgap/tmp-glibc/work/x86_64-linux/nodejs-native/20.12.2/node-v20.12.2'
do_configure

Checking ICU support at runtime

Please run bitbake -c devshell chromium-x11. From the devshell, create (using vim/nano/...) a test.js file with the following contents:

const hasICU = typeof process.versions.icu === 'string';
console.log(`hasICU: ${hasICU} version=${process.versions.icu}`);

const hasFullICU = (() => {
  try {
    const january = new Date(9e8);
    const spanish = new Intl.DateTimeFormat('es', { month: 'long' });
    return spanish.format(january) === 'enero';
  } catch (err) {
    return false;
  }
})();
console.log(`hasFullICU: ${hasFullICU}`);

const cmp = 'foo'.localeCompare('bar', 'en');
console.log(`cmp: ${cmp}`);

and then run third_party/node/linux/node-linux-x64/bin/node test.js and paste the output here. For my build, the output is this:

hasICU: true version=74.2
hasFullICU: true
cmp: 1

Running btest402

As above, please start a chromium-x11 devshell (or reuse the same one). Then download https://github.com/srl295/btest402/raw/master/btest402.js, e.g. using wget, and run third_party/node/linux/node-linux-x64/bin/node btest402.js and paste the output here. For my build, the output is this:

You have console.log.
Running btest..
+ Congrats, you have the Intl object.
en:
 date: (supported:en) Saturday, January 3, 1970
 Intl.v8BreakIterator error (NOT part of EcmaScript402): TypeError: Intl.v8BreakIterator is not a constructor

mt:
 date: (supported:mt) Is-Sibt, 3 ta’ Jannar 1970
 Intl.v8BreakIterator error (NOT part of EcmaScript402): TypeError: Intl.v8BreakIterator is not a constructor

ja:
 date: (supported:ja) 1970年1月3日土曜日
 Intl.v8BreakIterator error (NOT part of EcmaScript402): TypeError: Intl.v8BreakIterator is not a constructor

tlh:
 date: (supported:) Saturday, January 3, 1970
 Intl.v8BreakIterator error (NOT part of EcmaScript402): TypeError: Intl.v8BreakIterator is not a constructor


--------- Analysis ---------
* You have the 'Intl' object. Congratulations! You have the possibility of being EcmaScript 402 compliant.
* Klingon isn't a supported language by the date formatter. It is without honor!

----------------
SUMMARY:Have Intl, Date:no 'tlh',

MaxIhlenfeldt avatar May 20 '24 10:05 MaxIhlenfeldt

@MaxIhlenfeldt ,I have tried with clean build, but getting same issue. Did you observe same issue during you are testing.

@rjanani-p I haven't seen this specific error message in any local build I've done. As the error is related to Node's internationalization support, please provide the following information that hopefully helps with finding its cause. (reference: https://nodejs.org/api/intl.html)

Node build setup

The default for the nodejs recipe is to build Node with the --with-intl=system-icu option. Can you please check that this is the case for your build by running bitbake -e nodejs-native | grep -B 25 PACKAGECONFIG= and pasting the output here? For my build, the output is this:

# pre-expansion value:
#   "${PN}-${PV}"
P="nodejs-native-20.12.2"
#
# $PACKAGECONFIG [9 operations]
#   set /home/chromium/yocto-chromium/sources/poky/meta/conf/documentation.conf:321
#     [doc] "This variable provides a means of enabling or disabling features of a recipe on a per-recipe basis."
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:67
#     [_defaultval] "ares brotli icu zlib"
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:69
#     [ares] "--shared-cares,,c-ares"
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:70
#     [brotli] "--shared-brotli,,brotli"
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:71
#     [icu] "--with-intl=system-icu,--without-intl,icu"
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:72
#     [libuv] "--shared-libuv,,libuv"
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:73
#     [nghttp2] "--shared-nghttp2,,nghttp2"
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:74
#     [shared] "--shared"
#   set /home/chromium/yocto-chromium/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_20.12.2.bb:75
#     [zlib] "--shared-zlib,,zlib"
# pre-expansion value:
#   "ares brotli icu zlib"
PACKAGECONFIG="ares brotli icu zlib"

And to be completely sure, please run bitbake -c devshell nodejs-native and in that shell run grep -A 15 'do_configure()' ../temp/run.do_configure and paste the output here. For my build, the output is this:

do_configure() {
    GYP_DEFINES="${GYP_DEFINES}" export GYP_DEFINES
    # $TARGET_ARCH settings don't match --dest-cpu settings
    python3 configure.py --verbose --prefix=/home/chromium/yocto-chromium/builds/chromium-x11-qemux86-64-scarthgap/tmp-glibc/work/x86_64-linux/nodejs-native/20.12.2/recipe-sysroot-native/usr \
               --shared-openssl \
               --dest-cpu="x64" \
               --dest-os=linux \
               --libdir=lib \
               --no-cross-compiling \
                \
                --shared-cares --shared-brotli --with-intl=system-icu --shared-zlib
}

cd '/home/chromium/yocto-chromium/builds/chromium-x11-qemux86-64-scarthgap/tmp-glibc/work/x86_64-linux/nodejs-native/20.12.2/node-v20.12.2'
do_configure

Checking ICU support at runtime

Please run bitbake -c devshell chromium-x11. From the devshell, create (using vim/nano/...) a test.js file with the following contents:

const hasICU = typeof process.versions.icu === 'string';
console.log(`hasICU: ${hasICU} version=${process.versions.icu}`);

const hasFullICU = (() => {
  try {
    const january = new Date(9e8);
    const spanish = new Intl.DateTimeFormat('es', { month: 'long' });
    return spanish.format(january) === 'enero';
  } catch (err) {
    return false;
  }
})();
console.log(`hasFullICU: ${hasFullICU}`);

const cmp = 'foo'.localeCompare('bar', 'en');
console.log(`cmp: ${cmp}`);

and then run third_party/node/linux/node-linux-x64/bin/node test.js and paste the output here. For my build, the output is this:

hasICU: true version=74.2
hasFullICU: true
cmp: 1

Running btest402

As above, please start a chromium-x11 devshell (or reuse the same one). Then download https://github.com/srl295/btest402/raw/master/btest402.js, e.g. using wget, and run third_party/node/linux/node-linux-x64/bin/node btest402.js and paste the output here. For my build, the output is this:

You have console.log.
Running btest..
+ Congrats, you have the Intl object.
en:
 date: (supported:en) Saturday, January 3, 1970
 Intl.v8BreakIterator error (NOT part of EcmaScript402): TypeError: Intl.v8BreakIterator is not a constructor

mt:
 date: (supported:mt) Is-Sibt, 3 ta’ Jannar 1970
 Intl.v8BreakIterator error (NOT part of EcmaScript402): TypeError: Intl.v8BreakIterator is not a constructor

ja:
 date: (supported:ja) 1970年1月3日土曜日
 Intl.v8BreakIterator error (NOT part of EcmaScript402): TypeError: Intl.v8BreakIterator is not a constructor

tlh:
 date: (supported:) Saturday, January 3, 1970
 Intl.v8BreakIterator error (NOT part of EcmaScript402): TypeError: Intl.v8BreakIterator is not a constructor


--------- Analysis ---------
* You have the 'Intl' object. Congratulations! You have the possibility of being EcmaScript 402 compliant.
* Klingon isn't a supported language by the date formatter. It is without honor!

----------------
SUMMARY:Have Intl, Date:no 'tlh',

@MaxIhlenfeldt , I have followed the steps which you are shared and executed the commands. For last 2 commands getting below issue FATAL ERROR: DateTimePatternGeneratorCache::CreateGenerator Allocation failed - process out of memory. Here I am sharing the command results. nodejs_command_results.txt

Let me free up the memory in my workspace and let me start the clean build from my side. Could you please share your inputs to resolve the issue. Thank you!.

rjanani-p avatar May 20 '24 12:05 rjanani-p

@rjanani-p thanks!

Please also re-run the "Checking ICU support at runtime" and "Running btest402" after freeing up memory and paste the results here.

MaxIhlenfeldt avatar May 20 '24 13:05 MaxIhlenfeldt

@rjanani-p thanks!

Please also re-run the "Checking ICU support at runtime" and "Running btest402" after freeing up memory and paste the results here.

@MaxIhlenfeldt , I have tried again after free up the memory in workspace and tried with clean build but getting same issue. Do I need to set up any config for poky scarthgap?

attaching build configuration for reference: Build Configuration: BB_VERSION = "2.8.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "x86_64-poky-linux" MACHINE = "qemux86-64" DISTRO = "poky" DISTRO_VERSION = "5.0.1" TUNE_FEATURES = "m64 core2" TARGET_FPU = "" meta meta-poky meta-yocto-bsp = "scarthgap:4b07a5316ed4b858863dfdb7cab63859d46d1810" meta-filesystems meta-gnome meta-initramfs meta-multimedia meta-networking meta-oe meta-perl meta-python meta-webserver meta-xfce = "scarthgap:a72010b414ee3d73888ac9cb4e310e8f05e13aea" meta-clang = "scarthgap:e7dceb1c92caf7f21ef1d7b49c85328c30cffd90" meta-chromium = "123.0.6312.122:e490f4ad84328cddbe99b31fc4913729991c2145"

Checking ICU support at runtime: $third_party/node/linux/node-linux-x64/bin/node test.js hasICU: true version=74.2

<--- Last few GCs --->

<--- JS stacktrace --->

FATAL ERROR: DateTimePatternGeneratorCache::CreateGenerator Allocation failed - process out of memory ----- Native stack trace -----

1: 0x560ad9fa344f node::OOMErrorHandler(char const*, v8::OOMDetails const&) [third_party/node/linux/node-linux-x64/bin/node] 2: 0x560ada2ece74 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [third_party/node/linux/node-linux-x64/bin/node] 3: 0x560ada2ed133 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [third_party/node/linux/node-linux-x64/bin/node] 4: 0x560ada6ba20e v8::internal::JSDateTimeFormat::New(v8::internal::Isolate*, v8::internal::Handlev8::internal::Map, v8::internal::Handlev8::internal::Object, v8::internal::Handlev8::internal::Object, char const*) [third_party/node/linux/node-linux-x64/bin/node] 5: 0x560ada3711fa v8::internal::Builtin_DateTimeFormatConstructor(int, unsigned long*, v8::internal::Isolate*) [third_party/node/linux/node-linux-x64/bin/node] 6: 0x560adac96df6 [third_party/node/linux/node-linux-x64/bin/node] Aborted (core dumped)

Running btest402:

$third_party/node/linux/node-linux-x64/bin/node btest402.js You have console.log. Running btest..

  • Congrats, you have the Intl object. en:

<--- Last few GCs --->

<--- JS stacktrace --->

FATAL ERROR: DateTimePatternGeneratorCache::CreateGenerator Allocation failed - process out of memory ----- Native stack trace -----

1: 0x5654425a344f node::OOMErrorHandler(char const*, v8::OOMDetails const&) [third_party/node/linux/node-linux-x64/bin/node] 2: 0x5654428ece74 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [third_party/node/linux/node-linux-x64/bin/node] 3: 0x5654428ed133 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [third_party/node/linux/node-linux-x64/bin/node] 4: 0x565442cba20e v8::internal::JSDateTimeFormat::New(v8::internal::Isolate*, v8::internal::Handlev8::internal::Map, v8::internal::Handlev8::internal::Object, v8::internal::Handlev8::internal::Object, char const*) [third_party/node/linux/node-linux-x64/bin/node] 5: 0x565442cbb6ee v8::internal::JSDateTimeFormat::ToLocaleDateTime(v8::internal::Isolate*, v8::internal::Handlev8::internal::Object, v8::internal::Handlev8::internal::Object, v8::internal::Handlev8::internal::Object, v8::internal::JSDateTimeFormat::RequiredOption, v8::internal::JSDateTimeFormat::DefaultsOption, char const*) [third_party/node/linux/node-linux-x64/bin/node] 6: 0x565442967118 v8::internal::Builtin_DatePrototypeToLocaleString(int, unsigned long*, v8::internal::Isolate*) [third_party/node/linux/node-linux-x64/bin/node] 7: 0x565443296df6 [third_party/node/linux/node-linux-x64/bin/node] Aborted (core dumped)

rjanani-p avatar May 21 '24 04:05 rjanani-p

@rjanani-p I don't think you need any special setup. What's the output of free -k when you run it from the same devshell as third_party/node/linux/node-linux-x64/bin/node?

MaxIhlenfeldt avatar May 21 '24 14:05 MaxIhlenfeldt

@MaxIhlenfeldt - this v123 pull request is building and working with the Texas Instruments Scarthgap yocto and GPU acceleration is functional across PowerVR platforms (non-SGX) using chromium-ozone-wayland. With version 122 and 123 I have had to switch from --use-gl=egl to --use-gl=angle for GPU accel to work correctly. I also have pulled in this upstream chromium GPU patch:
https://chromium.googlesource.com/chromium/src/+/7efb6857a17195f08b609129e92732e19aa1d54c as it seemed potentially important, although nothing obviously bad was observed without it present with our current testing.

darren-etheridge avatar May 21 '24 18:05 darren-etheridge

@rjanani-p I don't think you need any special setup. What's the output of free -k when you run it from the same devshell as third_party/node/linux/node-linux-x64/bin/node?

@MaxIhlenfeldt , please find the free -k command results $ chromium/chromium_ver_builds/builds_chromium/build_poky_scarthgap_chrom_123_ver_2005/tmp/work/core2-64-poky-lbuilds_chromium/build_poky_scarthgap_chrom_123inux/chromium-x11/123.0.6312.122/chromium-123.0.6312.122# free -k total used free shared buff/cache available Mem: 263547740 6866504 13719392 4085144 242961844 250635508 Swap: 8388604 8388604 0

rjanani-p avatar May 22 '24 04:05 rjanani-p

@darren-etheridge thanks! Should you notice that the mentioned patch is needed in m123 after all, feel free to open an issue and I can add it as a backport.

MaxIhlenfeldt avatar May 22 '24 09:05 MaxIhlenfeldt

@rjanani-p hm, the only thing standing out to me is that your swap space is completely full even though there's enough memory still available. Other than "have you tried turning it off and on again" I'm out of ideas. I do think however that this "out of memory" issue could well be the root cause of Node's "ICU error" message - V8 calls out to ICU, and if that fails to allocate V8 will error out with exactly the message Node is displaying.

Given all this and the fact that m125 is already shipping to Stable, I'd propose merging this and investigating the Node error separately, so I can start working on the m124 update. @rakuco wdyt?

MaxIhlenfeldt avatar May 22 '24 09:05 MaxIhlenfeldt

Given all this and the fact that m125 is already shipping to Stable, I'd propose merging this and investigating the Node error separately, so I can start working on the m124 update. @rakuco wdyt?

Sounds good to me!

rakuco avatar May 22 '24 10:05 rakuco

@rjanani-p I ran into the same issue as you, same Allocation failed issue, but found the problem on my side.

Try executing node --help, do you also observe:

# third_party/node/linux/node-linux-x64/bin/node --help
Usage: node [options] [ script.js ] [arguments]
       node inspect [options] [ script.js | host:port ] [arguments]

Options:
node:internal/main/print_help:132
      return StringPrototypeLocaleCompare(name1, name2);
             ^

?

In my case LD_LIBRARY_PATH was not setup properly:

7 # ldd third_party/node/linux/node-linux-x64/bin/node --help
third_party/node/linux/node-linux-x64/bin/node:
        linux-vdso.so.1 (0x00007ffe56d96000)
        libpseudo.so => /home/buildbot/worker/WPE-Linux-RPi4-64bits-Mesa-Release-Perf-Build/build/WebKitBuild/CrossToolChains/rpi4-64bits-mesa/build/tmp/sysroots-components/x86_64/pseudo-na)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fae1bdb2000)
        libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007fae1bda5000)
        libbrotlienc.so.1 => /lib/x86_64-linux-gnu/libbrotlienc.so.1 (0x00007fae1950a000)
        libcares.so.2 => not found
        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fae19000000)
        libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007fae18f57000)
        libicui18n.so.74 => not found
        libicuuc.so.74 => not found
...

Fixing export LD_LIBRARY_PATH=$PWD/recipe-sysroot-native/usr/share/icu/74-2/lib:$LD_LIBRARY_PATH, solved the issue for me:

chromium-124.0.6367.207 # third_party/node/linux/node-linux-x64/bin/node test.js
hasICU: true version=74.2
hasFullICU: true
cmp: 1

Hope that helps.

nikolaszimmermann avatar Jun 29 '24 09:06 nikolaszimmermann

@rjanani-p I debugged this further with the help of @nikolaszimmermann tips and I found a bug on icu that causes libicudata to not be properly installed when you working with large paths (around 400-500+ characters). If you are also using long paths, then try applying this patch to icu: https://github.com/unicode-org/icu/pull/3058

clopez avatar Jul 01 '24 23:07 clopez