Bug 257378 - devel/electron12: Fails to build: third_party/nasm/include/compiler.h:249:21: error: static declaration of 'mempcpy' follows non-static declaration (stable/13 amd64)
Summary: devel/electron12: Fails to build: third_party/nasm/include/compiler.h:249:21:...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Many People
Assignee: Koichiro Iwao
URL:
Keywords: needs-qa
: 258829 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-07-24 08:05 UTC by Robert Cina
Modified: 2022-02-22 23:12 UTC (History)
9 users (show)

See Also:
bugzilla: maintainer-feedback? (tagattie)
koobs: merge-quarterly?


Attachments
electron12 poudriere log of build failiure on amd64 stable 13 (424.57 KB, text/plain)
2021-07-24 08:05 UTC, Robert Cina
no flags Details
Patch based on Bug257352 for www/chromium (1.51 KB, patch)
2021-08-07 14:45 UTC, Tomoaki AOKI
no flags Details | Diff
Patch based on Bug257352 and Bug258271 for www/chromium (1.67 KB, patch)
2021-09-19 05:47 UTC, Tomoaki AOKI
koobs: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Cina 2021-07-24 08:05:29 UTC
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);
Comment 1 Robert Cina 2021-07-25 01:33:17 UTC
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
Comment 2 Tomoaki AOKI 2021-08-07 14:45:18 UTC
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
Comment 3 Robert Cina 2021-08-07 16:14:55 UTC
Thanks. Will give this patch a try and report back on how it goes.
Comment 4 Robert Cina 2021-08-07 21:50:44 UTC
Electron seems to have built successfully here with this patch applied.
Thanks for the fix.
Comment 5 Tomoaki AOKI 2021-09-19 05:47:51 UTC
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.
Comment 6 Daniel Shafer 2021-09-19 05:52:02 UTC
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>
         ^~~~~~~~~~~~~~
Comment 7 Tomoaki AOKI 2021-09-19 07:11:07 UTC
(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.
Comment 8 Daniel Shafer 2021-09-19 08:02:12 UTC
(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.
Comment 9 Robert Cina 2021-09-30 20:54:19 UTC
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.
Comment 10 Kubilay Kocak freebsd_committer freebsd_triage 2021-10-01 05:19:15 UTC
*** Bug 258829 has been marked as a duplicate of this bug. ***
Comment 11 Kubilay Kocak freebsd_committer freebsd_triage 2021-10-01 05:22:28 UTC
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
Comment 12 Mark Millard 2021-10-02 20:37:09 UTC
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.)
Comment 13 Wes Morgan 2021-10-03 03:06:35 UTC
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
Comment 14 Tomoaki AOKI 2021-10-03 05:20:54 UTC
(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.
Comment 15 Koichiro Iwao freebsd_committer freebsd_triage 2021-10-04 00:12:43 UTC
Thanks for the patch. testbuild@work.
Comment 16 Mark Millard 2021-10-04 20:32:06 UTC
(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.)
Comment 17 commit-hook freebsd_committer freebsd_triage 2021-10-06 12:12:49 UTC
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(-)
Comment 18 commit-hook freebsd_committer freebsd_triage 2021-10-06 12:16:52 UTC
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(-)
Comment 19 Tomoaki AOKI 2021-10-06 12:44:49 UTC
(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.
Comment 20 Koichiro Iwao freebsd_committer freebsd_triage 2021-10-06 12:57:27 UTC
I think the original issue is fixed. So please file a new bug for other build issue.
Comment 21 Mark Millard 2021-10-06 15:51:24 UTC
(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.
Comment 22 Jonas Lopes 2021-10-08 12:16:37 UTC
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
Comment 23 Wes Morgan 2021-10-08 12:25:12 UTC
That looks a lot like a process being killed due to resource limit.
Comment 24 Jonas Lopes 2021-10-08 13:05:32 UTC
(In reply to Wes Morgan from comment #23)

Exactly!

I closed everything and ran again. It worked!

Thanks :)
Comment 25 Koichiro Iwao freebsd_committer freebsd_triage 2021-10-10 14:12:58 UTC
(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.
Comment 26 Mark Millard 2021-10-11 08:31:18 UTC
(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.)
Comment 27 Koichiro Iwao freebsd_committer freebsd_triage 2021-10-12 06:44:22 UTC
(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.
Comment 28 Mark Millard 2021-10-12 19:51:07 UTC
(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.
Comment 29 Mark Millard 2021-10-15 00:38:16 UTC
(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.
Comment 30 Mark Millard 2021-10-15 15:47:51 UTC
(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.
Comment 31 Kubilay Kocak freebsd_committer freebsd_triage 2022-02-22 23:12:46 UTC
^Triage: Assign to committer that resolved