Created attachment 226650 [details] electron12 poudriere log of build failiure on amd64 stable 13 The port devel/electron12 fails to build on amd64 stable 13 using poudriere with the following error: static declaration of 'mempcpy' follows non-static declaration static inline void *mempcpy(void *dst, const void *src, size_t n) ^ /usr/include/string.h:70:7: note: previous declaration is here void *mempcpy(void * __restrict, const void * __restrict, size_t);
Just want to add this is related to the same error occurring for the Chromium build bug where mempcpy was added to base libc as shown below: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257352
Created attachment 227006 [details] Patch based on Bug257352 for www/chromium Does this patch work for you? I myself cannot try due to dependency conflicts. (node, yarn,...) This is based on patch for Bug 257352. [1] Makefile part is modified to fit devel/electron12. (And date and time of original files.) [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257352
Thanks. Will give this patch a try and report back on how it goes.
Electron seems to have built successfully here with this patch applied. Thanks for the fix.
Created attachment 227998 [details] Patch based on Bug257352 and Bug258271 for www/chromium Avoid warning on previous patch while building Index for branches not yet MFC'ed mempcpy() addition. Actually, merge previous patch and proposed fix for www/chromium on Bug258271, v2 patch by Felix.
So the patch fixed the build problem stated in the ticket, but curious if anyone got this further down the line: ../../sandbox/linux/suid/sandbox.c:12:10: fatal error: 'asm/unistd.h' file not found #include <asm/unistd.h> ^~~~~~~~~~~~~~
(In reply to Daniel Shafer from comment #6) As I wrote on past comment, I myself cannot build-test devel/electron12 due to dependency conflict. would need some other person to look in and fix. Sorry. *I remember that initial devel/electron* port was derived from www/chromium and found this PR, so ported the fix for www/chromium by hand. But I "feel" it seems to be a lack of dependency. For my case, /compat/linux/usr/include/asm/unistd.h was installed by package linux-c7-devtools-7.9.2009 and www/chromium builds fine at git 9e6695a71d64. *Build after commit git 17218fbbe799 is on-going just now.
(In reply to Tomoaki AOKI from comment #7) So I added it as a dependency just to see, and it still wouldn't build. Not sure much about this, if there is anything I can test I will be happy to do so.
Sorry for being late to test this. I have just tested the patch from attachment 227998 [details] on my 13-stable amd64 system and it built fine for me using poudriere. Hopefully this helps.
*** Bug 258829 has been marked as a duplicate of this bug. ***
Comment on attachment 227998 [details] Patch based on Bug257352 and Bug258271 for www/chromium Pending QA checks confirmation: Approved by: portmgr (blanket: build fix) MFH: 202Q3
The patch allowed my attempt to build via poudriere-devel on amd64 to finish. I do not use electron12 but I've been testing doing bulk -a runs on a HoneyComb (16 Cortex-A72's) and wanted the activity to span bulding large things like electron12. The basic test for buildability is faster on the ThreadRipper 1950X, so that is what the test was done on. [01:24:48] [01] [01:24:41] Finished devel/electron12 | electron12-12.0.9_2: Success [01:24:52] Stopping 1 builders # uname -apKU FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #2 main-n249019-0637070b5bca-dirty: Tue Aug 31 01:27:48 PDT 2021 root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1400032 1400032 # pwd /usr/ports # ~/fbsd-based-on-what-commit.sh branch: main merge-base: 59611d61d70a85f4418f3f701db1b7baf58560ba merge-base: CommitDate: 2021-09-29 09:39:17 +0000 59611d61d70a (HEAD -> main) databases/postgresql14-server: fix openssl dependency n560161 (--first-parent --count for merge-base) (But with the patch applied.)
My build of electron12 still doesn't complete even with this patch. The logs make it look like a chromedriver build failure; I will try without it. -std=c11 -c ../../sandbox/linux/suid/sandbox.c -o obj/sandbox/linux/chrome_sandbox/sandbox.o ../../sandbox/linux/suid/sandbox.c:12:10: fatal error: 'asm/unistd.h' file not found #include <asm/unistd.h> ^~~~~~~~~~~~~~ 1 error generated. [ 60% 13/20] touch obj/electron/electron_mksnapshot_zip__deps.stamp [ 65% 13/20] python ../../electron/build/zip.py chromedriver.zip gen.runtime/electron/electron_chromedriver_zip/electron_chromedriver_zip.runtime_deps x64 freebsd false
(In reply to Wes Morgan from comment #13) Daniel or Wes: Can any of you file a new bug describing your failure mode? Both of you seem to have the same problem, but it isn't match the failure mode with this bug. It will make it easier for devel/electron12 developers to find your problem. At least, Robert and Mark could confirm build fine with the patch here. BTW, devel/electron12 depends on non-default version of node, yarn-node and npm-node, and yarn-node14 is FETCH_ and EXTRACT_ DEPENDed. This makes me impossible to even do `make extract` or `make patch` to look into problematic sources. www/chromium had the exactly same failure mode with this bug and devel/electron12 has the same patch in files/ directory. This is why I could port the fix for www/chromium to this, and why I cannot further help.
Thanks for the patch. testbuild@work.
(In reply to Mark Millard from comment #12) I've also now built it on aarch64 (HoneyComb with 16 Cortex-A72's and 64 GiByte of RAM): [00:02:30] Building 1 packages using 1 builders [00:02:30] Starting/Cloning builders [00:02:31] Hit CTRL+t at any time to see build progress and stats [00:02:31] [01] [00:00:00] Building devel/electron12 | electron12-12.0.9_2 [00:02:32] [01] [00:00:01] Warning: ALLOW_NETWORKING_PACKAGES: Allowing full network access for devel/electron12 | electron12-12.0.9_2 [04:57:10] [01] [04:54:39] Finished devel/electron12 | electron12-12.0.9_2: Success Side note on how to reproduce the success: I did add: ALLOW_NETWORKING_PACKAGES="electron12" to /usr/local/etc/poudriere.conf in order to avoid: yarn install v1.22.11 [1/4] Resolving packages... [2/4] Fetching packages... info There appears to be trouble with your network connection. Retrying... info There appears to be trouble with your network connection. Retrying... info There appears to be trouble with your network connection. Retrying... info There appears to be trouble with your network connection. Retrying... info There appears to be trouble with your network connection. Retrying... error An unexpected error occurred: "https://registry.yarnpkg.com/aws-sdk/-/aws-sdk-2.727.1.tgz: ESOCKETTIMEDOUT". info If you think this is a bug, please open a bug report with the information provided in "/wrkdirs/usr/ports/devel/electron12/work/yarn-error.log". info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command. info There appears to be trouble with your network connection. Retrying... info There appears to be trouble with your network connection. Retrying... info There appears to be trouble with your network connection. Retrying... info There appears to be trouble with your network connection. Retrying... info There appears to be trouble with your network connection. Retrying... *** Error code 1 This was not something I needed to do for amd64. I do not use electron12 but was just trying to test doing bulk -a builds and adjusting things to allow for such, including the big ports buling in parallel with other ports. I've not tested the electron12 tht was built. (No video in the system.)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=9cdeb88eac13fab9aed2f3972cef30d229890bde commit 9cdeb88eac13fab9aed2f3972cef30d229890bde Author: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> AuthorDate: 2021-10-06 08:52:26 +0000 Commit: Koichiro Iwao <meta@FreeBSD.org> CommitDate: 2021-10-06 12:11:29 +0000 devel/electron12: fix build In file included from ../../third_party/nasm/asm/assemble.c:178: ../../third_party/nasm/include/compiler.h:249:21: error: static declaration of 'mempcpy' follows non-static declaration static inline void *mempcpy(void *dst, const void *src, size_t n) ^ /usr/include/string.h:70:7: note: previous declaration is here void *mempcpy(void * __restrict, const void * __restrict, size_t); ^ PR: 257378 Reported by: Robert Cina <transitive@gmail.com> Tested by: meta Approved by: maintainer timeout (> 2 weeks) MFH: 2021Q4 devel/electron12/Makefile | 6 ++++++ devel/electron12/files/extra-patch-no-mempcpy-nasm (new) | 11 +++++++++++ .../files/patch-third__party_nasm_config_config-linux.h | 9 --------- 3 files changed, 17 insertions(+), 9 deletions(-)
A commit in branch 2021Q4 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d770515c66879c01deab29d91d575dc3b0872a2f commit d770515c66879c01deab29d91d575dc3b0872a2f Author: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> AuthorDate: 2021-10-06 08:52:26 +0000 Commit: Koichiro Iwao <meta@FreeBSD.org> CommitDate: 2021-10-06 12:13:58 +0000 devel/electron12: fix build In file included from ../../third_party/nasm/asm/assemble.c:178: ../../third_party/nasm/include/compiler.h:249:21: error: static declaration of 'mempcpy' follows non-static declaration static inline void *mempcpy(void *dst, const void *src, size_t n) ^ /usr/include/string.h:70:7: note: previous declaration is here void *mempcpy(void * __restrict, const void * __restrict, size_t); ^ PR: 257378 Reported by: Robert Cina <transitive@gmail.com> Tested by: meta Approved by: maintainer timeout (> 2 weeks) MFH: 2021Q4 (cherry picked from commit 9cdeb88eac13fab9aed2f3972cef30d229890bde) devel/electron12/Makefile | 6 ++++++ devel/electron12/files/extra-patch-no-mempcpy-nasm (new) | 11 +++++++++++ .../files/patch-third__party_nasm_config_config-linux.h | 9 --------- 3 files changed, 17 insertions(+), 9 deletions(-)
(In reply to Mark Millard from comment #16) I'm not at all familiar with poudriere, but seems that https://registry.yarnpkg.com/aws-sdk/-/aws-sdk-2.727.1.tgz is going to be fetched but not described in distinfo. If it doesn't appear on amd64 but aarc64, it can be a arch-specific dependency. *Assuming that the ALLOW_NETWORKING_PACKAGES setting is NOT needed for `make fetch` phase but build/install phase. Or just it was already set for amd64 and missing on aarc64.
I think the original issue is fixed. So please file a new bug for other build issue.
(In reply to Koichiro Iwao from comment #20) I do not consider the ALLOW_NETWORKING_PACKAGES="electron12" for aarch64 issue to be a bug, although it would be nice if something documented the potential for electron12 requiring such for non-amd64 contexts. I only proivded the note to help anyone else that decided to test in an aarch64 context.
I understand it could be a consequence. Another error: [ 99% 38457/38463] python "../../build/toolchain/gcc_link_wrapper.py" --output="./v8_context_snapshot_generator" -- c++ -fuse-ld=lld -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,--no-call-graph-profile-sort -m64 -Wl,-O2 -Wl,--gc-sections -rdynamic -pie -Wl,--disable-new-dtags -Wl,--icf=none -Wl,-rpath=\$ORIGIN -L/usr/local/lib -fstack-protector-strong -L/usr/local/lib -o "./v8_context_snapshot_generator" -Wl,--start-group @"./v8_context_snapshot_generator.rsp" -Wl,--end-group -lpthread -lgmodule-2.0 -lglib-2.0 -lgobject-2.0 -lgthread-2.0 -lintl -lnss3 -lsmime3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -ldl -lexecinfo -lkvm -lutil -lrt -ljpeg -lpng16 -lz -lxml2 -lxslt -llzma -lm -lgio-2.0 -lwebpdemux -lwebpmux -lwebp -lfreetype -lexpat -lfontconfig -lharfbuzz-subset -lharfbuzz -lopus -lavcodec -lavformat -lavutil -lopenh264 -lX11 -lXcomposite -lXdamage -lXext -lXfixes -lXrender -lXrandr -lXtst -lxcb -ldrm -lxkbcommon -lgbm -ldbus-1 -latk-1.0 -latk-bridge-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgtk-3 -lgdk-3 -lcairo-gobject -lgdk_pixbuf-2.0 -lXi -lGL -lpci -lasound -lsnappy -lcups FAILED: v8_context_snapshot_generator python "../../build/toolchain/gcc_link_wrapper.py" --output="./v8_context_snapshot_generator" -- c++ -fuse-ld=lld -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,--no-call-graph-profile-sort -m64 -Wl,-O2 -Wl,--gc-sections -rdynamic -pie -Wl,--disable-new-dtags -Wl,--icf=none -Wl,-rpath=\$ORIGIN -L/usr/local/lib -fstack-protector-strong -L/usr/local/lib -o "./v8_context_snapshot_generator" -Wl,--start-group @"./v8_context_snapshot_generator.rsp" -Wl,--end-group -lpthread -lgmodule-2.0 -lglib-2.0 -lgobject-2.0 -lgthread-2.0 -lintl -lnss3 -lsmime3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -ldl -lexecinfo -lkvm -lutil -lrt -ljpeg -lpng16 -lz -lxml2 -lxslt -llzma -lm -lgio-2.0 -lwebpdemux -lwebpmux -lwebp -lfreetype -lexpat -lfontconfig -lharfbuzz-subset -lharfbuzz -lopus -lavcodec -lavformat -lavutil -lopenh264 -lX11 -lXcomposite -lXdamage -lXext -lXfixes -lXrender -lXrandr -lXtst -lxcb -ldrm -lxkbcommon -lgbm -ldbus-1 -latk-1.0 -latk-bridge-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgtk-3 -lgdk-3 -lcairo-gobject -lgdk_pixbuf-2.0 -lXi -lGL -lpci -lasound -lsnappy -lcups c++: error: unable to execute command: Killed c++: error: linker command failed due to signal (use -v to see invocation) ninja: build stopped: subcommand failed. *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/electron12 *** Error code 1 Stop. make: stopped in /usr/ports/editors/vscode
That looks a lot like a process being killed due to resource limit.
(In reply to Wes Morgan from comment #23) Exactly! I closed everything and ran again. It worked! Thanks :)
(In reply to Jonas Lopes from comment #24) 32 GB was not enough for me. Maybe it requires more than 32 GB of main memory.
(In reply to Koichiro Iwao from comment #25) If you were using poudriere(-devel), what did you use for USE_TMPFS= . . . ? How big of a(?) swap partition is in use? Does swapon report any mistuning notices? How many processes were allowed? What other activity was allowed in parallel with the electron12 build (if any)? For the likes of USE_TMPFS=all or even including wrkdir , electron12 uses over 20 GiByte of storage during building, which for such USE_TMPFS values is competing for RAM+SWAP. (I've likely not observed a near-peak figure, just some example figures during building.)
(In reply to Mark Millard from comment #26) Thanks for the point, I didn't care about the value of USE_TMPFS but actually, it was USE_TMPFS=yes. Poudriere build was performed on 16GB main memory + 16 GB swap on SSD. When I add 16GB swap (total: 16GB + 32GB swap), the build finished.
(In reply to Koichiro Iwao from comment #27) Yea, USE_TMFS=yes is equivalent to USE_TMPFS="wrkdir data" and including wrkdir leads to 20+ GiBytes of tmpfs use just for wrkdir.
(In reply to Mark Millard from comment #21) I started a build on a Rock64 (aarch64, 4-core, 4 GiByte of RAM) without ALLOW_NETWORKING_PACKAGES and it got past that point without problems. So architecture does not seem to be what makes the distinction. Folks wanting to test should just know that ALLOW_NETWORKING_PACKAGES might be required, at least until someone figures out what makes the difference.
(In reply to Koichiro Iwao from comment #27) On a Rock64 (aarch64, 4 Cortex-A53 cores, 4 GiBytes of RAM), with a root-on-UFS file system and a 14336Mi swap partition active (but little used compared to its size as it turned out), I built devel/electron12 : . . . (52 other ports built first) . . . [10:35:31] [01] [00:00:00] Building devel/electron12 | electron12-12.0.9_2 [101:27:33] [01] [90:52:02] Finished devel/electron12 | electron12-12.0.9_2: Success [101:29:05] Stopping 4 builders . . . (Only one builder was active during devel/electron12.) It was based on (in part): USE_TMPFS=no ALLOW_PARALLEL_JOBS= Also in use was /boot/loader.conf having: vm.pageout_oom_seq=120 vm.pfault_oom_attempts=-1 to avoid processes being likely to be killed for sustained durations of low free RAM or for slow paging I/O. I have larger than default poudriere timout settings. I'll not detail them here. My local top has patches that record and report various "Maximum Observed" figures (MaxObs???? naming). Starting top shortly after the "Building devel/electron12" notice was reported: . . . load averages: . . . MaxObs: 9.11, 8.34, 7.94 . . . threads: . . . 18 MaxObsRunning . . . Mem: . . . 3120Mi MaxObsActive, 792064Ki MaxObsWired, 3921Mi MaxObs(Act+Wir+Lndry) Swap: 14336Mi Total . . . 2383Mi MaxObsUsed, 5381Mi MaxObs(Act+Lndry+SwapUsed), 6142Mi MaxObs(Act+Wir+Lndry+SwapUsed) So RAM+SwapUsed was somewhat over (4+2.3) GiBytes, i.e., RAM+SwapUsed of somwhat over 6.3 GiBytes for the 4 FreeBSD cpu context when avoiding tmpfs use.
^Triage: Assign to committer that resolved