Re: git: 58dba5b8212f - main - devel/llvm19: prune build on 32-bit archs

On Aug 28, 2024, at 11:30, Mark Millard <marklmi@yahoo.com> wrote:

> On Aug 28, 2024, at 05:35, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
> 
>> On Tue, 27 Aug 2024 18:15:41 -0700
>> Mark Millard <marklmi@yahoo.com> wrote:
>> 
>>> Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp> wrote on
>>> Date: Tue, 27 Aug 2024 23:29:35 UTC :
>>> 
>>>> Shouldn't BE_WASM kept as default?
>>>> 
>>>> www/firefox depends on devel/wasi-*17, and IIRC, devel/wasi-*17 depends
>>>> on devel/llvm17 with BE_WASM enabled.
>>>> 
>>>> And www/firefox doesn't have ONLY_FOR_ARCHS and NOT_FOR_ARCHS defined.
>>> 
>>> When I look up the active 140releng-armv7-default build, www/firefox
>>> and www/firefox-esr were skipped because of rust-1.79.0_1 not being
>>> available.
>>> 
>>> lang/rust (in turn) had failed to build:
>>> 
>>> =======================<phase: build >============================
>>> ===== env: NO_DEPENDS=yes USER=root UID=0 GID=0
>>> ===> Building for rust-1.79.0_1
>>> Building bootstrap
>>> running: /wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo build --manifest-path /wrkdirs/usr/ports/lang/rust/work/rustc-1.79.0-src/src/bootstrap/Cargo.toml --verbose --verbose --frozen
>>> Traceback (most recent call last):
>>> File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.79.0-src/x.py", line 50, in <module>
>>> bootstrap.main()
>>> File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.79.0-src/src/bootstrap/bootstrap.py", line 1165, in main
>>> bootstrap(args)
>>> File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.79.0-src/src/bootstrap/bootstrap.py", line 1132, in bootstrap
>>> build.build_bootstrap()
>>> File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.79.0-src/src/bootstrap/bootstrap.py", line 888, in build_bootstrap
>>> run(args, env=env, verbose=self.verbose, cwd=self.rust_root)
>>> File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.79.0-src/src/bootstrap/bootstrap.py", line 187, in run
>>> raise RuntimeError(err)
>>> RuntimeError: failed to run: /wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo build --manifest-path /wrkdirs/usr/ports/lang/rust/work/rustc-1.79.0-src/src/bootstrap/Cargo.toml --verbose --verbose --frozen
>>> *** Error code 1
>>> 
>>> Stop.
>>> make: stopped in /usr/ports/lang/rust
>>> =>> Cleaning up wrkdir
>>> ===> Cleaning for rust-1.79.0_1
>>> build of lang/rust | rust-1.79.0_1 ended at Sun Aug 25 13:39:13 UTC 2024
>>> build time: 00:03:22
>>> !!! build failure encountered !!!
>>> 
>>> 
>>> portsfallout.com <http://portsfallout.com/> reports for lang/rust:
>>> 
>>> port maintainer build environment category date urls
>>> lang/rust rust@FreeBSD.org 140releng-armv7-default build 2024-08-25 13:36 log report port detail FreshPorts
>>> lang/rust rust@FreeBSD.org 140releng-armv7-default build 2024-07-25 14:15 log report port detail FreshPorts
>>> lang/rust rust@FreeBSD.org 140releng-armv7-default build 2024-07-08 00:15 log report port detail FreshPorts
>>> lang/rust rust@FreeBSD.org 140releng-armv7-default build 2024-06-24 03:53 log report port detail FreshPorts
>>> lang/rust rust@FreeBSD.org 140releng-armv7-default build 2024-06-13 22:03 log report port detail FreshPorts
>>> lang/rust rust@FreeBSD.org 140releng-armv7-default build 2024-06-01 02:15 log report port detail FreshPorts
>>> lang/rust rust@FreeBSD.org 140releng-armv7-default build 2024-05-19 03:51 log report port detail FreshPorts
>>> lang/rust rust@FreeBSD.org 140releng-armv7-default build 2024-05-06 04:28 log report port detail FreshPorts
>>> lang/rust rust@FreeBSD.org 140releng-armv7-default build 2024-04-23 02:10 log report port detail FreshPorts
>>> lang/rust rust@FreeBSD.org 140releng-armv7-default build 2024-04-08 09:22 log report port detail FreshPorts
>>> 
>>> It looks like everything dependent on lang/rust is effectively
>>> broken for armv7 and has been for 5 months (or more), at least
>>> for the FreeBSD package builders and their procedures. (The
>>> reasons may vary over time. I've not looked at the detail.)
>>> 
>>> 133releng-armv7-default and 132releng-armv7-default look
>>> to have a similar status to 140releng-armv7-default as far
>>> as lang/rust failing so everything depending on lang/rust
>>> being broken.
>>> 
>>> 133releng-armv7-quarterly and 132releng-armv7-quarterly
>>> and 140releng-armv7-quarterly all look to have a similar
>>> status to 140releng-armv7-default as far as lang/rust
>>> failing so everything depending on lang/rust being broken.
>>> 
>>> Currently, the status of BE_WASM does not seem to matter
>>> much for 14.0 or for main [so: 15], at least for the
>>> FreeBSD package builders and their procedures.
>>> 
>>> 
>>> 
>>> Note: I used 140releng-armv7-default because building
>>> main-armv7-default had hangup problems for months (except
>>> when other failing ports blocked trying to build what
>>> showed the hangup problems). So main-armv7-default
>>> history from much of this year is not particularly
>>> useful.
>>> 
>>> ===
>>> Mark Millard
>>> marklmi at yahoo.com
>> 
>> Hm, this kind of problem should be fixed by Rust guys.
>> Because (according to https://www.freshports.org/lang/rust/) amd64
>> and aarch64 has 1.79.0_1 has lang/rust at 1.79.0_1 for all 13, 14
>> and current. In addition, i386 has it except for current.
>> So it should be the problem of current Rust or its bootstrap.
>> 
>> What we need considering is that BE_WASM should be kept default or not
>> after the Rust problem is fixed.
>> 
> 
> Hello.
> 
> Looking back at an old log for which building armv7 www/firefox was
> attempted on ampere2 ( 140releng-armv7-quarterly 2f4b45697768 ):
> 
> memory allocation of 72901804 bytes failed
> error: could not compile `style` (lib)
> 
> and:
> 
> /wrkdirs/usr/ports/www/firefox/work/firefox-124.0.1/media/libtheora/lib/arm/armcpu.c:152:3: error: "Configured to use ARM asm but no CPU detection method available for " "your platform. Reconfigure with --disable-asm (or send patches)."
> # error "Configured to use ARM asm but no CPU detection method available for " \
> ^
> 1 error generated.
> 
> See: http://ampere1.nyi.freebsd.org/build.html?mastername=140releng-armv7-quarterly&build=2f4b45697768
> 
> A similar point goes for www/firefox-esr relative to memory use:
> 
> LLVM ERROR: out of memory
> Allocation failed
> error: could not compile `gkrust` (lib)
> 
> See: http://ampere1.nyi.freebsd.org/data/140releng-armv7-quarterly/2f4b45697768/logs/errors/firefox-esr-115.9.1,1.log
> 
> 
> It is, unfortunately, very difficut to figure out the most recent
> time that an armv7 www/firefox or www/firefox-esr build completed
> successfully on any official FreeBSD package builder --even if it
> was within the records that are still kept for any ampere* .
> Prior to the ampere* 's it likely never built under qemu because
> of qemu problems that blocked most ports from building (most
> being skipped).
> 
> It may be that armv7 firefox has never managed to build in the
> FreeBSD package server based builds. Similarly for forefox-esr .

I looked up the:

https://firefox-source-docs.mozilla.org/contributing/build/supported.html

document and for firefox build hosts mozilla only lists
examples of x86_64 (some linux variants, macOS, Windows)
and the Apple M1 (macOS). (The Apple M1 does not support
armv7 in its hardware.)

Thus: no 32-bit context of any kind.

So, even though ARMv7 Android on Linux is a Tier-1 target
platform and is also a Tier-3 Linux platform (only), no
ARMv7 is a supported build platform.

My guess would be that lack of ready build-ability on
32-bit platforms is an issue for more than FreeBSD.

FYI:
"Tier-3 platforms have a maintainer or community which
attempt to keep the platform working."

The FreeBSD target contexts mentioned are only listed
as being for Tier-3: FreeBSD/x86, x86-64, Aarch64 (clang)
"maintained by gecko@FreeBSD.org". No mention of armv7.


===
Mark Millard
marklmi at yahoo.com