Closed ZerdoX-x closed 11 months ago
Compilation failed with ozone_platform_x11
. Is error related to arm64?
UPD: Trying to emerge with system-av1
... Probably will respond tomorrow as I leave compilation over night.
And your USE flags are…?
-X -bluetooth +clang +cups -custom-cflags -debug -dev-dependencies -gtk4 -hangouts -hevc -kerberos -optimize-thinlto -optimize-webui -paxkernel +pgo +proprietary-codecs +pulseaudio +screencast -system-abseil-cpp +system-av1 -system-brotli -system-crc32c -system-double-conversion -system-ffmpeg +system-harfbuzz +system-icu +system-jsoncpp +system-libevent +system-libusb -system-libvpx +system-openh264 -system-openjpeg +system-png -system-re2 +system-snappy -system-woff2 +system-zstd -thinlto +ungoogled -vaapi +wayland
Since I cannot launch app-editors/vscodium::gentoo
binary, it just provides no errors even with --verbose
, I am trying to use app-editors/vscode::pf4public
which requires +system-re2
on electron, now I am recompiling it once again, but still, with ozone_platform_x11
. For now I am just interested why electron requires this flag for me to properly get configured. Also hope that vscode from your overlay will work for me. I have no electron apps in my environment and I have never used it, not sure what is the source of problems causing vscode to misbehave.
clang cups proprietary-codecs pulseaudio screencast system-av1 system-harfbuzz system-icu system-jsoncpp system-libevent system-libusb system-openh264 system-png system-re2* system-snappy ungoogled wayland -X -custom-cflags -debug -dev-dependencies -gtk4 -hangouts -hevc -kerberos (-nvidia) -optimize-thinlto -optimize-webui -pax-kernel -pgo* -pic% (-selinux) -suid% -system-abseil-cpp -system-brotli -system-crc32c -system-double-conversion -system-ffmpeg -system-libvpx -system-openjpeg -system-woff2 -thinlto -vaapi (-bluetooth%) (-system-zstd%*)
/var/tmp/portage/dev-util/electron-25.9.3/temp/build.log: https://0x0.st/Hy5N.log
Now linker fails.. I'll disable LTO for electron
Disabling LTO doesn't work:
FAILED: chrome_sandbox
"python3.11" "../../build/toolchain/gcc_link_wrapper.py" --output="./chrome_sandbox" -- clang++ -pie -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-mllvm,-enable-machine-outliner=never -no-canonical-prefixes -Wl,-O2 -Wl,--gc-sections -rdynamic -Wl,-z,defs -Wl,--as-needed -pie -Wl,--disable-new-dtags -Wl,--as-needed -o "./chrome_sandbox" -Wl,--start-group @"./chrome_sandbox.rsp" -Wl,--end-group -latomic -ldl -lpthread -lrt
/usr/bin/aarch64-unknown-linux-gnu-ld.bfd: unrecognised emulation mode: llvm
Supported emulations: aarch64linux aarch64elf aarch64elf32 aarch64elf32b aarch64elfb armelf armelfb aarch64linuxb aarch64linux32 aarch64linux32b armelfb_linux_eabi armelf_linux_eabi
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
Trying to compile with gcc
app-editors/vscode::pf4public which requires +system-re2 on electron
It does not. What led you to such conclusion?
Now linker fails..
Please do not ignore issue template that states:
Please provide any relevant information including the full build log. Please don't use external services for that.
I'll disable LTO for electron
LTO works just fine.
First you tried 27, now you're building 25. You constantly change flags, you do not provide full build logs. Stop this chaos right away please.
Sure, I got you, sorry. I am removing all my redundant use flags, envs, etc. Just trying to emerge app-editors/vscode::pf4public
as it was first time.
My explicit USE flags on electron are -pgo ungoogled
emerge -av app-editors/vscode
:
[ebuild N #] dev-util/electron-25.9.3:25/9.3::pf4public USE="clang cups proprietary-codecs pulseaudio screencast system-harfbuzz system-icu system-jsoncpp system-libevent system-libusb system-openh264 system-png system-re2 system-snappy ungoogled wayland -X -custom-cflags -debug -dev-dependencies -gtk4 -hangouts -hevc -kerberos (-nvidia) -optimize-thinlto -optimize-webui -pax-kernel -pgo -pic (-selinux) -suid -system-abseil-cpp -system-av1 -system-brotli -system-crc32c -system-double-conversion -system-ffmpeg -system-libvpx -system-openjpeg -system-woff2 -thinlto -vaapi" CPU_FLAGS_ARM="(-neon)" L10N="-af -am -ar -bg -bn -ca -cs -da -de -el -en-GB -es -es-419 -et -fa -fi -fil -fr -gu -he -hi -hr -hu -id -it -ja -kn -ko -lt -lv -ml -mr -ms -nb -nl -pl -pt-BR -pt-PT -ro -ru -sk -sl -sr -sv -sw -ta -te -th -tr -uk -ur -vi -zh-CN -zh-TW" 0 KiB
[ebuild N #] app-editors/vscode-1.83.1::pf4public USE="temp-fix -api-proposals -badge-providers -build-online -electron-19 -electron-20 -electron-21 -electron-22 -electron-23 -electron-24 -electron-26 -electron-27 -openvsx -reh -reh-web -substitute-urls" 0 KiB
Total: 2 packages (2 new), Size of downloads: 0 KiB
For some reason I cannot upload build.log
using attachments, I get error in devtools console in both librewolf and chromium browsers: POST https://objects-origin.githubusercontent.com/github-production-repository-file-5c1aeb net::ERR_ACCESS_DENIED
I created a gist for you: https://gist.github.com/ZerdoX-x/f8b1add4fa866a2379965133f969fb44
Looks like electron pulls x11 in: https://github.com/electron/electron/blob/6b6783977020438dd01dcbe8162585300d5e6148/BUILD.gn#L611C1-L612C34
So EXTRA_GN="ozone_platform_x11=true"
is indeed needed for it co configure. Perhaps I should add this to ebuild permanently.
You will also need use_lld=true
in EXTRA_GN
or alternatively build with USE=thinlto
in order to get over /usr/bin/aarch64-unknown-linux-gnu-ld.bfd: unrecognised emulation mode: llvm
error. I cannot tell you why LTO failed because you didn't provide logs for me to examine, ~but I would guess that you need to upgrade llvm to at least version 17 for it to work~ but that might've been OOM condition.
For some reason I cannot upload build.log using attachments
Maybe GitHub accepts compressed attachment better.
Added EXTRA_GN="use_lld=true ozone_platform_x11=true"
to /etc/portage/env/dev-util/electron
Maybe GitHub accepts compressed attachment better.
I just forgot to chown the build log after copying it to my home dir :D
app-editors/vscode::pf4public which requires +system-re2 on electron
It does not. What led you to such conclusion?
emerge -av dev-util/electron
:
[ebuild N #] dev-util/electron-27.0.2:27/0.2::pf4public USE="clang cups proprietary-codecs pulseaudio screencast system-harfbuzz system-icu system-jsoncpp system-libevent system-libusb system-openh264 system-png system-snappy system-zstd ungoogled wayland -X -bluetooth -custom-cflags -debug -dev-dependencies -gtk4 -hangouts -hevc -kerberos (-nvidia) -optimize-thinlto -optimize-webui -pax-kernel -pgo (-selinux) -system-abseil-cpp -system-av1 -system-brotli -system-crc32c -system-double-conversion -system-ffmpeg -system-libvpx -system-openjpeg -system-re2 -system-woff2 -thinlto -vaapi"
emerge -av app-editors/vscode
:
[ebuild N #] dev-util/electron-25.9.3:25/9.3::pf4public USE="clang cups proprietary-codecs pulseaudio screencast system-harfbuzz system-icu system-jsoncpp system-libevent system-libusb system-openh264 system-png system-re2 system-snappy ungoogled wayland -X -custom-cflags -debug -dev-dependencies -gtk4 -hangouts -hevc -kerberos (-nvidia) -optimize-thinlto -optimize-webui -pax-kernel -pgo -pic (-selinux) -suid -system-abseil-cpp -system-av1 -system-brotli -system-crc32c -system-double-conversion -system-ffmpeg -system-libvpx -system-openjpeg -system-woff2 -thinlto -vaapi"
[ebuild N #] app-editors/vscode-1.83.1::pf4public USE="temp-fix -api-proposals -badge-providers -build-online -electron-19 -electron-20 -electron-21 -electron-22 -electron-23 -electron-24 -electron-26 -electron-27 -openvsx -reh -reh-web -substitute-urls"
At first I just compiled electron from your repo, hoping that vscodium::gentoo
binary will launch, no luck. I compiled electron successfully with EXTRA_GN="ozone_platform_x11=true"
and system-av1
USE flag enabled, but I had to unmerge it since as I already said.. Ohh.... These are different electron versions. And now I understand that probably electron was built-in in that vscodium binary that gentoo distributes. Yes, sorry. Just ignore this whole part of the message :)
Also, If I can compile electron 27 with no issues (except system-av1, which must be provided by system in my case). Maybe I can use vscode Nvm, I can see they just migrated to electron 25 https://github.com/microsoft/vscode/issues/184021 That's why vscode package wanted to downgrade my previous electron. I should have tried to compile vscode with electron 27 though :D I think I'll let it compile for another 5 hours over night, while waiting for your feedback if issue above is resolvable.electron-27
USE flag? Why would we spend time on trying to compile "outdated" version of electron?
except system-av1, which must be provided by system in my case
What led you to such conclusion? You can use av1 shipped with chromium.
../../base/cpu.h:90:3: error: unknown type name 'uint8_t'
This might be gcc-13 incompatibility. I would suggest you try electron-27. Alternatively you can try adding #include <cstdint>
in base/cpu.h
. There could be other similar failures, so you'd better try electron-27 anyway.
What led you to such conclusion? You can use av1 shipped with chromium.
third_party/libaom/source/libaom/av1/common/arm/compound_convolve_neon_i8mm.c
fails for me:
error: always_inline function 'vusdotq_s32' requires target feature 'i8mm', but would be inlined into function 'convolve4_4_2d_h' that is compiled without support for 'i8mm'
I also found this. This is probably related to arm64 / M1 cpu. I am not sure what i8mm means. Btw M1/M2/M3 cpu on linux use 16K pages, maybe this also leads to some of the errors while compiling, idk.
UPDATE: can be fixed by https://github.com/PF4Public/gentoo-overlay/issues/271#issuecomment-1854941728
There could be other similar failures, so you'd better try electron-27 anyway.
Sure, I have compiled electron-27 successfully, however, configuring vscode does not pass, related to cpu arch.
This is probably related to arm64
Most likely!
Sure, I have compiled electron-27 successfully, however, configuring vscode does not pass, related to cpu arch.
Would you be able to add arm/arm64 condition(s) (in the same manner as existing ones) and test whether you can move forward? I don't have arm hardware, therefore I never tested ebuilds on arm. You seem to be the first one to attempt them on arm :D
Would you be able to add arm/arm64 condition(s) (in the same manner as existing ones) and test whether you can move forward?
Sure. I have created local overlay, copied vscode from your overlay to mine, added arm64 and tried:
Same goes for 1.84:
Do you have python-3.11? It fails due to python-3.12.
Do you have python-3.11? It fails due to python-3.12.
Yes.
equery l "*python*"
gives both 3.11 and 3.12
python3 --version
gives 3.11
equery b python3
:
dev-lang/python-3.11.6 (/usr/lib/python-exec/python3.11/python3 -> ../../../bin/python3.11)
dev-lang/python-3.12.0_p1 (/usr/lib/python-exec/python3.12/python3 -> ../../../bin/python3.12)
dev-lang/python-exec-2.4.10 (/usr/bin/python3 -> python-exec2c)
As you can see in the build log, it chooses 3.12
Ty. Sorry for delay, was busy welcoming the new year of my life ;)
Release/obj.target/vscode-policy-watcher/src/main.o: file not recognized: file format not recognized
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [vscode-policy-watcher.target.mk:146: Release/obj.target/vscode-policy-watcher.node] Error 1
make: Leaving directory '/var/tmp/portage/app-editors/vscode-1.84.0/work/vscode-1.84.0/node_modules/@vscode/policy-watcher/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack at ChildProcess.onExit (/usr/lib64/electron-27/node_modules/npm/node_modules/node-gyp/lib/build.js:203:23)
gyp ERR! stack at ChildProcess.emit (node:events:514:28)
gyp ERR! stack at Process.onexit (node:internal/child_process:291:12)
gyp ERR! System Linux 6.5.0-asahi-15-edge-ARCH
gyp ERR! command "/usr/lib64/electron-27/electron" "/usr/lib64/electron-27/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /var/tmp/portage/app-editors/vscode-1.84.0/work/vscode-1.84.0/node_modules/@vscode/policy-watcher
gyp ERR! node -v v18.17.1
gyp ERR! node-gyp -v v9.3.1
gyp ERR! not ok
[01:38:58] [mangler] Mangling /var/tmp/portage/app-editors/vscode-1.84.0/work/vscode-1.84.0/extensions/typescript-language-features/tsconfig.json
<--- Last few GCs --->
[29:0x380b4e0000] 3145 ms: Scavenge 95.1 (106.6) -> 92.0 (108.8) MB, 3.44 / 0.00 ms (average mu = 0.994, current mu = 0.994) allocation failure;
[29:0x380b4e0000] 3161 ms: Scavenge 97.7 (109.3) -> 94.3 (111.5) MB, 3.34 / 0.00 ms (average mu = 0.994, current mu = 0.994) allocation failure;
[29:0x380b4e0000] 3181 ms: Scavenge 100.1 (111.8) -> 96.5 (112.3) MB, 6.59 / 0.00 ms (average mu = 0.994, current mu = 0.994) allocation failure;
<--- JS stacktrace --->
FATAL ERROR: NewSpace::EnsureCurrentCapacity Allocation failed - JavaScript heap out of memory
/usr/lib64/electron-27/node: line 3: 28 Aborted ELECTRON_RUN_AS_NODE=1 $(dirname "$0")/electron "${@}"
* ERROR: app-editors/vscode-1.84.0::zerdox failed (compile phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 136: Called src_compile
* environment, line 3112: Called die
* The specific snippet of code:
* node --max_old_space_size=8192 node_modules/gulp/bin/gulp.js vscode-linux-${VSCODE_ARCH}-min || die;
Disabled LTO for vscode. How to overcome nodejs heap issues?
How to overcome nodejs heap issues?
You cannot. This thing happens from time to time. Continue the build or restart the build from scratch.
EDIT: --max_old_space_size=8192
was supposed to fix that and it indeed fixed that long time ago, but this issue reappeared recently. Unfortunately I had no time to debug it so far.
Sheeesh
--max_old_space_size=10192
didn't work either. But --max_old_space_size=12192
worked from a first attempt for me.
Could you please add arm64 support? Because package itself has arm64 support but you didn't added that condition
I hope vscode will work fine with electron 27, just wish they could upgrade ASAP, even I don't really plan to use vscode, just wanted to test one unique extension for it
Btw, electron requires npm
flag for nodejs, which conflicts with corepack
flag, is this not resolvable? Gentoo team does not want to add slots for nodejs, so I don't really know how to overcome this. Do you know what corepack is? It it possible to utilize it?
I am a frontend developer and I heavily rely on nodejs, and I would like to keep corepack, it's actually more important to me to have corepack rather then having ability to use shitty electron apps ;)
UPD: Actually I could use something like fnm (nvm but better, node version manager) to install nodejs for my personal use, as I do with rustup. But I am still curios.
You can add ozone_platform_x11
, add arm64 support and the whole issue is resolved.
Not sure about LLD and max_old_space_size
. Second one preventing me from switching from my own local overlay to yours one.
Also.. Do you know if code-oss picks code-flags.conf
? Because for me it does not pick it up, maybe it's different name or smth?
But --max_old_space_size=12192 worked from a first attempt for me.
That might've been a coincidence. Try again several times, would it be consistently a success? If yes, then you've found the fix — great!
Sheeesh
I'm glad you made it!
Could you please add arm64 support?
Would you like to submit PR?
I hope vscode will work fine with electron 27
Works for me.
I don't really plan to use vscode
It's a pity :D
ability to use shitty electron apps ;)
vscode included? ;)
Btw, electron requires npm flag for nodejs
Yep, see https://github.com/PF4Public/gentoo-overlay/issues/154
code-oss picks code-flags.conf?
Probably not. Never used them.
Try again several times, would it be consistently a success?
Sure, I'll try to compile 5 times and give feedback here. I have tried to compile with 8 gigs 3-4 times, no success. One time with 10 gigs, no success. One time with 12 gigs is success. Anyways it will depend on each machine and each setup, not sure if we need to change it in the current ebuild. I would assume that.. Why not? Most laptops/desktops have either 8 or 16 gigs of memory, and I don't think current ebuild will success on 8 gig setup, so it's not a big deal I think. If person has low end machine but wants to compile vscode himself, he might try to lower amount of memory himself as I did, but in another way.
Would you like to submit PR?
Yeah, thank you. Maybe today, maybe in a couple of days. Quite busy now, but I'll do it :+1:
Works for me.
That's great to hear
I don't really plan to use vscode
It's a pity :D
I am a vim chad yk XD
ability to use shitty electron apps ;)
vscode included? ;)
Yeah any product. Using electon as a developer (/team) is a sin, especially when Tauri arrived. BTW thank you for the overlay :DDD
Yep, see https://github.com/PF4Public/gentoo-overlay/issues/154
Will take a look later, thanks. I have already switched from system node to FNM (which anyways give you ability to use system node when you want to)
Let's keep this open just until will push changes to the ebuilds that we discovered here. Thanks!
Sure, I'll try to compile 5 times and give feedback here.
So, how did it go?
So, how did it go?
Sorry for THAT delay :) Got quite busy. It worked for me.
Sorry for THAT delay :) Got quite busy. It worked for me.
5 times in a row without issues? Perhaps I should consider increasing the limit by default then…
What led you to such conclusion? You can use av1 shipped with chromium.
third_party/libaom/source/libaom/av1/common/arm/compound_convolve_neon_i8mm.c
fails for me:error: always_inline function 'vusdotq_s32' requires target feature 'i8mm', but would be inlined into function 'convolve4_4_2d_h' that is compiled without support for 'i8mm'
I also found this. This is probably related to arm64 / M1 cpu. I am not sure what i8mm means. Btw M1/M2/M3 cpu on linux use 16K pages, maybe this also leads to some of the errors while compiling, idk.
If anyone finds this thread and bumps into the same compile error, please add i8mm to your -march
like this:
COMMON_FLAGS="-march=armv8.4-a+simd+crypto+i8mm+bf16 -mtune=native -O2 -pipe"
Source: https://wiki.gentoo.org/wiki/User:Jared/Gentoo_On_An_M1_Mac
So EXTRA_GN="ozone_platform_x11=true" is indeed needed for it co configure. Perhaps I should add this to ebuild permanently.
1) Could you please add ozone_platform_x11
to ebuild?
2) and increase max_old_space_size
from 8192
to 12192
?
If these two will be added, issue can be completely closed, all of the problems caused by my rare setup are resolved :D
I just would like to remove my package.env overrides so I can just use your ebuilds "as is"
- Could you please add
ozone_platform_x11
to ebuild?
Sure
2. and increase
max_old_space_size
from8192
to12192
?
I tried that, but it didn't improve CI. If that makes it better at least on arm, I can restore it of course.
Also.. Do you know if code-oss picks code-flags.conf? Because for me it does not pick it up, maybe it's different name or smth?
There was an error by the way. Should work now.
Hi! Thank you for your overlay and maintaining it. Trying to compile electron on arm64 with wayland (without xwayland), error below:
UPD: Tried setting
EXTRA_GN="ozone_platform_x11=true"
, configuring passed, we'll see how it goes.