Re: Cross compiling user applications for armv7
Mark Millard <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
[Another note and some typo references.] On Sep 14, 2025, at 06:54, 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?] "I mixed instructions for", instead of "missed" them. > 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. > 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 <[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