Re: Cross compiling user applications for armv7

this is all why i just gave up, built whole system and ran it in full qemu vm

this was 10 years ago

this is slower but it does produce correct output for every port and even standalone code. if vm was started in beginning of this conversation, it would be ready now i guess, unless it's rust

yes, that is wrong way but is quite unfortunate how it's the only working way now. it's not fully fbsd fault too because all that code in ~33k ports is never written by any of them. and much of that code expects to run in actual machine

i don't know how linux managed to lie it up there. maybe they just have some beautiful layer on top that hides how it works. or maybe all build systems just work under linux. who knows

at least i gave up and ran vm. it's not that bad either

i got my "native" "buildenv" mostly up now but vm works  better. i don't run poudriere yet

i collected most of my tools up and put them here:

http://ketas.si.pri.ee/misc/fbsd-build-system.1757718768/

or

http://ketas.si.pri.ee/misc/fbsd-build-system.1757718768.txz

or, excuse me, but i also attached this 8k txz file here for future "safe keeping". sorry for enlarging mail(archive)s, tho, someone did attach several megs of images just recently

i hope maybe they have some use in (embedded) dev work

but yes, fbsd has super complex way here. and i say that after all those years since i installed my first system with 4.6 in 2002

so i'm not surprised this irritated the mkru



On September 14, 2025 5:54:18 PM GMT+03:00, "Michał Kruszewski" <[email protected]> wrote:
>
>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 <[email protected]> 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 [email protected] wrote:
>> 
>> > On Sep 14, 2025, at 05:46, Michał Kruszewski [email protected] 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 [email protected] 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
>