Re: Cross compiling user applications for armv7

> So your context replicated the qemu hangup that I reported to
> Warner from my attempt at doing a tiny build [poudriere(-devel)
> itself, with pkg also building]. What version of FreeBSD was
> involved in the replication. (Mine was a main 16 boot
> kernel and world and poudriere jail world.)

14.3 for host and target.

> Additional question: over what timescale might the need
> for armv7 support to last?
>
> While lib32 support for armv7 may last indefinitely,
> including whatever in the kernel is required for that,
> I'm unclear on the long term status of either of:
>
> ) chroot into an armv7 world
> ) jails based on an armv7 world
>
> after freebsd 16.* (FreeBSD 17+).
>
> poudiere(-devel) based port package builds depends on:
> jails.
>
> f jails were not to be supported indefinitely, could you
> get by with targeting FreeBSD 16.*-RELEASE's indefinitely
> but not FreeBSD 17 or later? Something to think about.
>
> While FreeBSD 16.* will have armv7 kernels, after that
> has no such guarantee --and seems unlikely for the kernel
> to support booting atively, given that even for FreeBSD
> 16.*-RELEASE armv7 is the last and only 32-bit boot
> context supported by a FreeBSD 16.* kernel.
>
> If the support time frame is spanned by FreeBSD 16.* then
> this might not be a problem. But it you need the support
> after that, ???Regards,

Basically, the message is "don't use FreeBSD for armv7 embedded development".
Maybe you are right.
I just wanted to try.
However, based on the number of problems I have encountered even for such a primary build, it looks like FreeBSD is not a good alternative for Linux in embedded domain.

Regards,
Michał


Sent with Proton Mail secure email.

On Monday, September 22nd, 2025 at 5:35 AM, Sulev-Madis Silber <freebsd-arm-freebsd-org097@ketas.si.pri.ee> wrote:

> meanwhile i also got my hopefully self-describing 13-5-release-armv7-local-common poudriere repo built with just ports-mgmt/pkg in it which took 01:16:24 on my c2d with user qemu taking all (or should i say both) cores
> 
> this is considerably slower. no, this is are you fucking kidding me slow, rather (compared to even this old host)
> 
> btw does poudriere/pkg need to scream out those
> 
> pkg-static: Both ABI_FILE and OSVERSION are set, ABI_FILE overrides OSVERSION
> 
> lines, there are number of those warnings in pkg and many of them are oh i already know
> 
> but yeah, hw is faster. actually i can't see anyone doing embedded dev without an actual hw so maybe it's not so bad suggestion to make some of dev boxes also a build machines where the needs and sad fbsd reality require this. also allows one to test that it works
> 
> sure, the rootless modes are better but we also have jails and vm's and i find it troubling if developers would repeateatedly break the build/dev infrastructure? i mean they are supposed to be trusted? it's like similar to office kitchen where you aren't supposed to break cups there apart from accidents
> 
> oh and root is usually removed for security purposes, and here i see no benefits too. i mean say you build nonroot but then use use it root? and that all in 2025 where you could have dedicated piece of hw for each task. there are no mainframes one per town anymore. so, unsure really
> 
> the good security practices don't really say avoid root at all costs, even if it stops you doing things
> 
> you know, it's weird too. people are convinced that root is bad, but sudo with your own password is somehow more secure? less scary, "safe", but same permissions? i find it ridiculous. it's as if it's better to cut bread with spoon and not use knife
> 
> maybe this false sense of sudo security has not found it's way onto (f)bsd that much, hence those requirements
> 
> i don't know eh...