Re: [zstd-sys 2.0.1+zstd.1.5.2] crate failing on arm64
Date: Thu, 24 Nov 2022 15:00:52 UTC
On Nov 24, 2022, at 03:03, Nuno Teixeira <eduardo@freebsd.org> wrote:
> Hello Mark,
>
> I have compared some of errors/warnings with amd64 build logs and they are present in there too.
>
> I think I found a glitch at the end of arm64 log:
> ---
> [zstd-sys 2.0.1+zstd.1.5.2] running: "ar" "cq" "/wrkdirs/usr/ports...
> (...)
> "/wrkdirs/usr/ports/editors/lapce/
> work/target/aarch64-unknown-freebsd/release/build/zstd-sys-97d70ebd740964f8/out/zstd/lib/decompress/huf_decompress_amd64.o"
> ^^^^^
> ---
> and zstd-sys-2.0.1+zstd.1.5.2/zstd/lib/common/xxhash.h:
> # if (defined(__aarch64__) || defined(__arm64__) || defined(_M_ARM64) || defined(_M_ARM64EC)) \
>
> So I presume that this crate should be build on arm64/aarch64 but don't understant why it calls:
> "huf_decompress_amd64.o"
>
> Any clues?
Not at this point. I've got the system rebuilding the
port so I can set up to look again.
(I note a better search string later below.)
> Mark Millard <marklmi@yahoo.com> escreveu no dia quinta, 24/11/2022 à(s) 04:46:
> Nuno Teixeira <eduardo_at_freebsd.org> wrote on
> Date: Thu, 24 Nov 2022 00:33:24 UTC :
>
> > For some time I'm receiving errors from build servers about editors/lapce
> > not building on arm64.
> >
> > From the log it seems [zstd-sys 2.0.1+zstd.1.5.2] crate failing.
> >
> > Is anybody with same problem?
> > I need to be sure before open an issue at upstream.
> >
> > What I don't understad is that upstream provides aarch64 pre-compiled
> > binaries...
> > https://github.com/lapce/lapce/releases/tag/v0.2.4
> >
> > https://pkg-status.freebsd.org/ampere2/data/main-arm64-default/pf323e9d40f68_s41be508d31/logs/lapce-0.2.4.log
>
>
> My ports tree is somewhat older but also produces the
> unexplained "*** Error code 101" (as did the FreeBSD
> build servers for the same version I'm testing here):
>
> # tail -20 /usr/local/poudriere/data/logs/bulk/main-CA72-default/2022-11-23_18h50m22s/logs/errors/lapce-0.2.1.log
> [libgit2-sys 0.13.4+1.4.2] cargo:rerun-if-changed=libgit2/deps/pcre/pcre_string_utils.c
> [libgit2-sys 0.13.4+1.4.2] cargo:rerun-if-changed=libgit2/deps/pcre/ucp.h
> [libgit2-sys 0.13.4+1.4.2] cargo:rerun-if-changed=libgit2/deps/pcre/pcre_ord2utf8.c
> [libgit2-sys 0.13.4+1.4.2] cargo:rerun-if-changed=libgit2/deps/pcre/pcre_byte_order.c
> [libgit2-sys 0.13.4+1.4.2] cargo:rerun-if-changed=libgit2/deps/pcre/pcre_fullinfo.c
> [libgit2-sys 0.13.4+1.4.2] cargo:rerun-if-changed=libgit2/deps/pcre/pcre_compile.c
> [libgit2-sys 0.13.4+1.4.2] cargo:rerun-if-changed=libgit2/deps/pcre/pcre_get.c
> [libgit2-sys 0.13.4+1.4.2] cargo:rerun-if-changed=libgit2/deps/pcre/pcre_dfa_exec.c
> [libgit2-sys 0.13.4+1.4.2] cargo:rerun-if-changed=libgit2/deps/pcre/config.h.in
> [libgit2-sys 0.13.4+1.4.2] cargo:rerun-if-changed=libgit2/deps/pcre/pcre_xclass.c
> [libgit2-sys 0.13.4+1.4.2] cargo:rerun-if-changed=libgit2/deps/pcre/pcre_globals.c
> *** Error code 101
>
> Stop.
> make: stopped in /usr/ports/editors/lapce
> =>> Cleaning up wrkdir
> ===> Cleaning for lapce-0.2.1
> build of editors/lapce | lapce-0.2.1 ended at Wed Nov 23 19:20:37 PST 2022
> build time: 00:22:50
> !!! build failure encountered !!!
>
> So may be the below will be suggestive/useful.
>
>
> I'll note that the "*** Error code 101" ended up not being
> anyhwere near were the problems(!) actually were. So likely
> for you the "zstd-sys 2.0.1+zstd.1.5.2" need not be one of
> the actual failure places.
>
>
> How I found the problems and what they look like . . .
>
> I did the bulk build with -w and expanded the tar:
>
> # mkdir -p /wrkdirs/usr/ports/editors/lapce
> # tar -xpf /usr/local/poudriere/data/wrkdirs/main-CA72-default/default/lapce-0.2.1.tbz -C /wrkdirs/usr/ports/editors/lapce
>
> I then went exploring. What I eventually found is quickly shown
> via:
>
> # find -s /wrkdirs/usr/ports/editors/lapce/ -name stderr -exec grep -l "aborting due to previous error" {} \; | less
A better string would have been just "aborting due to" that
would match when there was a count in the message as well.
> /wrkdirs/usr/ports/editors/lapce/work/target/aarch64-unknown-freebsd/debug/build/cap-primitives-ed08064314a4640b/stderr
> /wrkdirs/usr/ports/editors/lapce/work/target/aarch64-unknown-freebsd/debug/build/cap-std-5acaec63374cb836/stderr
> /wrkdirs/usr/ports/editors/lapce/work/target/aarch64-unknown-freebsd/debug/build/io-extras-e83e1591d250cc25/stderr
> /wrkdirs/usr/ports/editors/lapce/work/target/aarch64-unknown-freebsd/debug/build/io-lifetimes-62b7366622512d7e/stderr
> /wrkdirs/usr/ports/editors/lapce/work/target/aarch64-unknown-freebsd/debug/build/system-interface-56dbb6efd7f0321e/stderr
>
> There could be non-empty stderr files with other text that are
> also indications of failure. There are more stderr files. But
> the other few that I looked at did not seem to be indicating
> failures, more like informational/warning information.
>
> Text from some of the above stderr files:
>
> # less /wrkdirs/usr/ports/editors/lapce/work/target/aarch64-unknown-freebsd/debug/build/cap-primitives-ed08064314a4640b/stderr
> . . .
>
>
>
> It looks like, for rust based builds, such a "search through
> the stderr files" from a bulk -w like tar of the failure is
> the basic technique needed to identify the actual problems
> and where they were.
===
Mark Millard
marklmi at yahoo.com