Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Nov 2022 07:00:52 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        Nuno Teixeira <eduardo@freebsd.org>
Cc:        FreeBSD Mailing List <freebsd-ports@freebsd.org>
Subject:   Re: [zstd-sys 2.0.1+zstd.1.5.2] crate failing on arm64
Message-ID:  <7AB31838-8D70-4D48-A1F8-2FE8C8E7AA0E@yahoo.com>
In-Reply-To: <CAFDf7ULKuSUETZS4WLs3%2Bcepn94%2BnagY2OitNWoLP-JNjZUOGA@mail.gmail.com>
References:  <96078C14-CBEB-4450-ACE1-EB0488DD1814.ref@yahoo.com> <96078C14-CBEB-4450-ACE1-EB0488DD1814@yahoo.com> <CAFDf7ULKuSUETZS4WLs3%2Bcepn94%2BnagY2OitNWoLP-JNjZUOGA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 24, 2022, at 03:03, Nuno Teixeira <eduardo@freebsd.org> wrote:

> Hello Mark,
>=20
> I have compared some of errors/warnings with amd64 build logs and they =
are present in there too.
>=20
> 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-97d70ebd740964f=
8/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)) \
>=20
> So I presume that this crate should be build on arm64/aarch64 but =
don't understant why it calls:
> "huf_decompress_amd64.o"
>=20
> 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 =
=C3=A0(s) 04:46:
> Nuno Teixeira <eduardo_at_freebsd.org> wrote on
> Date: Thu, 24 Nov 2022 00:33:24 UTC :
>=20
> > For some time I'm receiving errors from build servers about =
editors/lapce
> > not building on arm64.
> >=20
> > =46rom the log it seems [zstd-sys 2.0.1+zstd.1.5.2] crate failing.
> >=20
> > Is anybody with same problem?
> > I need to be sure before open an issue at upstream.
> >=20
> > What I don't understad is that upstream provides aarch64 =
pre-compiled
> > binaries...
> > https://github.com/lapce/lapce/releases/tag/v0.2.4
> >=20
> > =
https://pkg-status.freebsd.org/ampere2/data/main-arm64-default/pf323e9d40f=
68_s41be508d31/logs/lapce-0.2.4.log
>=20
>=20
> 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):
>=20
> # 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=3Dlibgit2/deps/pcre/pcre_string_utils.c
> [libgit2-sys 0.13.4+1.4.2] =
cargo:rerun-if-changed=3Dlibgit2/deps/pcre/ucp.h
> [libgit2-sys 0.13.4+1.4.2] =
cargo:rerun-if-changed=3Dlibgit2/deps/pcre/pcre_ord2utf8.c
> [libgit2-sys 0.13.4+1.4.2] =
cargo:rerun-if-changed=3Dlibgit2/deps/pcre/pcre_byte_order.c
> [libgit2-sys 0.13.4+1.4.2] =
cargo:rerun-if-changed=3Dlibgit2/deps/pcre/pcre_fullinfo.c
> [libgit2-sys 0.13.4+1.4.2] =
cargo:rerun-if-changed=3Dlibgit2/deps/pcre/pcre_compile.c
> [libgit2-sys 0.13.4+1.4.2] =
cargo:rerun-if-changed=3Dlibgit2/deps/pcre/pcre_get.c
> [libgit2-sys 0.13.4+1.4.2] =
cargo:rerun-if-changed=3Dlibgit2/deps/pcre/pcre_dfa_exec.c
> [libgit2-sys 0.13.4+1.4.2] =
cargo:rerun-if-changed=3Dlibgit2/deps/pcre/config.h.in
> [libgit2-sys 0.13.4+1.4.2] =
cargo:rerun-if-changed=3Dlibgit2/deps/pcre/pcre_xclass.c
> [libgit2-sys 0.13.4+1.4.2] =
cargo:rerun-if-changed=3Dlibgit2/deps/pcre/pcre_globals.c
> *** Error code 101
>=20
> Stop.
> make: stopped in /usr/ports/editors/lapce
> =3D>> Cleaning up wrkdir
> =3D=3D=3D>  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 !!!
>=20
> So may be the below will be suggestive/useful.
>=20
>=20
> 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.
>=20
>=20
> How I found the problems and what they look like . . .
>=20
> I did the bulk build with -w and expanded the tar:
>=20
> # mkdir -p /wrkdirs/usr/ports/editors/lapce
> # tar -xpf =
/usr/local/poudriere/data/wrkdirs/main-CA72-default/default/lapce-0.2.1.tb=
z -C /wrkdirs/usr/ports/editors/lapce
>=20
> I then went exploring. What I eventually found is quickly shown
> via:
>=20
> # 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
>=20
> 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.
>=20
> Text from some of the above stderr files:
>=20
> # less =
/wrkdirs/usr/ports/editors/lapce/work/target/aarch64-unknown-freebsd/debug=
/build/cap-primitives-ed08064314a4640b/stderr
> . . .
>=20
>=20
>=20
> 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.



=3D=3D=3D
Mark Millard
marklmi at yahoo.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7AB31838-8D70-4D48-A1F8-2FE8C8E7AA0E>