Re: Cross compiling user applications for armv7

From: Mark Millard <marklmi_at_yahoo.com>
Date: Sun, 14 Sep 2025 15:47:01 UTC
[Another note and some typo references.]

On Sep 14, 2025, at 06:54, Mark Millard <marklmi@yahoo.com> wrote:

> [Sorry: I missed instructions for targeting main 16 [16.0-CURRENT] and
> instructions for targeting 14.3-RELEASE. Which are you after?]

"I mixed instructions for", instead of "missed" them.

> On Sep 14, 2025, at 06:44, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> On Sep 14, 2025, at 05:46, Michał Kruszewski <mkru@protonmail.com> wrote:
>> 
>>> I have finally managed
>>> poudriere jail -c -x -j armv7 -m git+https -a arm.armv7 -v releng/14.3 -K GENERIC
>>> to work.
>>> I see that it cross compiles the systems.
>>> This is pointless and redundant as I have already cross compiled the system on my own.
>> 
>> It does involve a reference to the source tree used. I
>> do not know your your PATH_TO_ARMV7_SYS_DIR . I show
>> deleting the above jail creation as well.
> 
> The below targets 16.0-CURRENT instead f 14.3-RELEASE.
> 
>> # poudriere jail -d -jarmv7
>> # poudriere jail -c -jarmv7 -a arm.armv7 -m null -M PATH_TO_ARMV7_SYS_DIR -S /usr/src/ -v 16.0-CURRENT
> 
> -v 14.3-RELEASE would be in the alternative.
> 
>> That presumes that qemu-user-static is already installed
>> and that the likes of:
>> 
>> # binmiscctl enable armv7
>> 
>> has already been done.
>> 
>> It sets up for references to the system toolchain to
>> be natively executed for cross build activity. But
>> it does not set up for any other toolchain references
>> to be natively executed.
>> 
>> 
>> One alternative to that based on official binary builds:
>> 
>> There is a way for poudriere to create its jail from official
>> pre-built binaries and still have that property ( I show deleting
>> the prior jail as well ):
> 
> The below targets 14.3-RELEASE instead of 16.0-CURRENT.
> 
>> # poudriere jail -d -jarmv7
>> # poudriere jail -c -jarmv7 -aarmv7 -U https://pkg.freebsd.org -mpkgbase=base_release_3 -v 14
> 
> -mpkgbase=base_latest -v 16 would be in the alternative.
> 
>> That presumes that qemu-user-static is already installed
>> and that the likes of:
>> 
>> # binmiscctl enable armv7
>> 
>> has already been done. It sets up for references to the
>> system toolchain to be natively executed. But it does
>> not set up for any other toolchain references to be
>> natively executed.
>> 
>>> How can I tell poudriere to use the system I have compiled on my own?
>> 
>> See above.
>> 
>>> I also started wondering why is qemu even required?
>> 
>> A lot of the ports tree does not use the system
>> toolchain at all, for example, instead using
>> other port-tree packages that are alternate
>> toolchain materials.
>> 
>> The ports-package based toolchains are not set
>> up for doing cross builds and ports using
>> alternative toolchains do not try to do
>> cross-build instances of the alternate
>> toolchains.
> 

There is also the scale for trying to change
things globally across the ports tree:

There are over 33600 active ports, that,
overall, specify over 37000 port-packages.
Reworking all that manually is a rarity,
given the volunteers available.

[I got the 33600+ ports figure from:

https://www.freshports.org/how-big-is-it.php

and got the 37000+ port-packages figure
from the Queued figure at:

https://pkg-status.freebsd.org/beefy18/build.html?mastername=main-amd64-default&build=p118fb2971704_s4ab64e34911
]

>>> The cross compiler toolchain is already prepared and ready-to-use after system compilation.
>> 
>> Not for the toolchains used by many ports.
>> See above.
>> 
>>> The ports descriptions already exist.
>>> Why can't I simply cross compile ports?
>> 
>> The infrastructure is set up to to use the
>> system toolchain natively --but not to
>> natively use any other toolchain.
>> 
>>> This task does not require qemu,
>> 
>> The way FreeBSD and its ports tree is set up: yes
>> it does.
>> 
>> You are speculating about a noy-FreeBSD-as-it-is

"not-FreeBSD-as-it-is", instead of "noy-FreeBSD-as-it-is".

>> context that might be technically possible to
>> create someday but that does not now exist.
>> 
>>> as I don't want to run resulting binaries on host.
>>> I just wont to cross compile ports and place them on the target file system.
>>> Qemu shouldn't be required for that.
>> 
>> Sorry, but it is required as things are. Note that
>> Warner's notes to you and void's notes to you and
>> my notes to you all are referencing the involvement
>> of qemu-user-static. Same for the poudriere-devel
>> man page.
>> 
>> FreeBSD's official port-package builds have always
>> involved qemu-user-static when native hardware was
>> not in use. They would not waste the time and
>> resources for such contexts if an alternative had
>> been in place.
>> 
>>> Regards,
>>> Michał Kruszewski
>>> 
>>> 
>>> Sent with Proton Mail secure email.
>>> 
>>> On Sunday, September 14th, 2025 at 2:33 PM, void <void@f-m.fm> wrote:
>>> 
>>>> Hello,
>>>> 
>>>> On Sun, Sep 14, 2025 at 09:24:07AM +0000, Michał Kruszewski wrote:
>>>> 
>>>>> I actually build system from the current main branch.
>>>>> How do I set up poudriere in such a case?
>>>> 
>>>> 
>>>> I'd do it like this, on amd64:
>>>> 
>>>> install poudriere-devel and configure poudriere.conf for your system.
>>>> (copy /usr/local/etc/poudriere.conf.sample to poudriere.conf and
>>>> edit it)
>>>> install qemu-user-static
>>>> run this: 'binmiscctl enable armv7'
>>>> then
>>>> 
>>>> poudriere jail -c -j armv7 -J10 -a arm.armv7 -m git+https -K GENERIC-NODEBUG -v main
>>>> 
>>>> the -J corresponding to the number of cores you may have.
>>>> 
>>>> Note that poudriere uses qemu-user-static for cross-compilation and
>>>> you can't build rust (or anything that uses rust) with it, as far as
>>>> I'm aware.
>>>> --
>> 
>> 
> 
> Sorry for the screwup.



===
Mark Millard
marklmi at yahoo.com