Date: Thu, 24 Nov 2022 09:26:51 -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: <D8C48CA3-665D-434E-AB9E-496451B0DA5B@yahoo.com> In-Reply-To: <7AB31838-8D70-4D48-A1F8-2FE8C8E7AA0E@yahoo.com> References: <96078C14-CBEB-4450-ACE1-EB0488DD1814.ref@yahoo.com> <96078C14-CBEB-4450-ACE1-EB0488DD1814@yahoo.com> <CAFDf7ULKuSUETZS4WLs3%2Bcepn94%2BnagY2OitNWoLP-JNjZUOGA@mail.gmail.com> <7AB31838-8D70-4D48-A1F8-2FE8C8E7AA0E@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 24, 2022, at 07:00, Mark Millard <marklmi@yahoo.com> wrote:
> On Nov 24, 2022, at 03:03, Nuno Teixeira <eduardo@freebsd.org> wrote:
>=20
>> Hello Mark,
Hello.
>> I have compared some of errors/warnings with amd64 build logs and =
they are present in there too.
Interesting.
>> 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"
>> =
=
^^^^^
Well, in my older context,
# grep "^#" =
/wrkdirs/usr/ports/editors/lapce/work/lapce-0.2.1/cargo-crates/zstd-sys-2.=
0.1+zstd.1.5.2/zstd/lib/decompress/huf_decompress_amd64.S | grep -v =
"#define "
#include "../common/portability_macros.h"
#if defined(__ELF__) && defined(__GNUC__)
#endif
#if ZSTD_ENABLE_ASM_X86_64_BMI2
#undef GET_NEXT_DELT
#undef DECODE_FROM_DELT
#undef DECODE
#undef RELOAD_BITS
#undef DECODE
#undef RELOAD_BITS
#endif
The #endif is the last line of the file and, ignoring
comments and blank lines for the most part, the rest
of the file before/at the #if ZSTD_ENABLE_ASM_X86_64_BMI2
is just:
#include "../common/portability_macros.h"
/* Stack marking
* ref: https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart
*/
#if defined(__ELF__) && defined(__GNUC__)
.section .note.GNU-stack,"",%progbits
#endif
#if ZSTD_ENABLE_ASM_X86_64_BMI2
Looks like the ZSTD_ENABLE_ASM_X86_64_BMI2 test would eliminate the
amd64 specifics in an aarch64 context, so they do not bother avoiding
the file.
>> ---
>> 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?
>=20
> Not at this point. I've got the system rebuilding the
> port so I can set up to look again.
>=20
>> . . .
FYI: the better string for searching got:
# find -s /wrkdirs/usr/ports/editors/lapce/ -name stderr -exec grep -l =
"aborting due to" {} \; | less
=
/wrkdirs/usr/ports/editors/lapce/work/target/aarch64-unknown-freebsd/debug=
/build/cap-fs-ext-10fe2c1f66453130/stderr
=
/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
The first line of the output is new compared to before:
# more =
/wrkdirs/usr/ports/editors/lapce/work/target/aarch64-unknown-freebsd/debug=
/build/cap-fs-ext-10fe2c1f66453130/stderr
error[E0554]: `#![feature]` may not be used on the stable release =
channel
--> <anon>:1:12
|
1 | #![feature(windows_by_handle)]
| ^^^^^^^^^^^^^^^^^
error[E0635]: unknown feature `windows_by_handle`
--> <anon>:1:12
|
1 | #![feature(windows_by_handle)]
| ^^^^^^^^^^^^^^^^^
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0554, E0635.
For more information about an error, try `rustc --explain E0554`.
So, not a new type of error compared to the others.
=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?D8C48CA3-665D-434E-AB9E-496451B0DA5B>