Re: Cross compiling user applications for armv7

From: Michał_Kruszewski <mkru_at_protonmail.com>
Date: Sun, 14 Sep 2025 14:54:18 UTC
Ok, I am slowly starting to see the bigger picutre.
I have to start from scratch and understand more details, because the amount of knowledge I had to gain this weekend blows my mind.

There is still one thing I don't see.
I have a custom C application with Python builtin as interpreter.
I will try to compile python using poudriere.
However, I don't want to deploy my program as a package.
In my case, it only makes things harder and there are no benefits.
I rather prefer to build my application using buildenv.
This means, that I have to install python libraries and headers (prepared by poudriere) for buildenv.
How do I do that?
Do I manually copy them to the subdirectories within the world and kernel installation directory?
Where will I find poudriere compilation output products?


Regards,
Michał Kruszewski


Sent with Proton Mail secure email.

On Sunday, September 14th, 2025 at 3:55 PM, 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?]
> 
> 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.
> > 
> > > 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
> > 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