Multi Arch ELF binary/object compiling, linking and more

[Michael Vale]

Sorry, there is more.  I forgot to mention that you can set X_SYSROOT at the command line so ports can find the appropriate system headers to build from as a part of your firmware.  You can also set DESTDIR to a valid jail and set CHROOTED to YES (more on that later) or NO=and specify a subdirectory within your jail to isolate your compilations from what would be a foreign HOST environment.  Or you can do what I did and edir Warden to create a mips template built from freebsd sources and push your host environment out into the build environment and have the jail contain only the firmware kernel and userland + the results of any ports you compile and install into that jail with DESTDIR CHROOTED=yes

From: m.vale at live.com.au
To: adrian at freebsd.org; bapt at freebsd.org; freebsd-mips at freebsd.org; freebsd-arm at freebsd.org; freebsd-embedded at freebsd.org
Subject: Multi Arch ELF binary/object compiling, linking and more
Date: Thu, 6 Aug 2015 13:20:27 +1030




You can try and read my lyrics off of this paper before I lay 'emBut you won't take the sting out these words before I say 'emCause ain't no way I'ma let you stop me from causing mayhemWhen I say I'ma do something I do it,I don't give a damn what you think,I'm doing this for me, so fuck the worldFeed it beans, it's gassed up, if it thinks it's stopping mehttps://www.youtube.com/watch?v=j5-yKhDd64s

Hey,
Okay here it is.  It's not complete yet, but I'm throwing it out there while I have the chance.
One can specify the build machine's arch type with ARCH=, the host (and in turn the build machine if one is not set) with X_BUILD_FOR= and also finally the target with TARGET=.  You can choose to set all three to the same arch as the target, or whatever pleases you.  Surely if you're smart and doing some wicked fancy things you can benefit from setting different archs accordingly, if you're accessing these binaries and objects from a central storage and utilising resources over a network.
EDIT: What I forgot to mention is, to utilize "cross-compiling" allows one to run the same binaries and objects on multiple architectures.  So one would think the build variable would have to be one of the machine compiling the binaries and objects but that is not the case, it has other purposes too.  It has been clear in the GNU and FreeBSD way of things that by retaining the build variable as the one you compile the binary on and setting the HOST variable defines what "other" (sic.) architecture the binaries or object execute on when infact by setting HOST, you also tend to automatically adjust TARGET to suit.  The light on this matter is that you can infact set an intermediate HOST architecture to the TARGET that allows building tasks assigned to the BUILD variable, 'hosting' and 'operating' on the HOST architecture and native execution on the TARGET.  Don't think for one moment though that you can't set all three BUILD, HOST and TARGET to the TARGET architecture and use that binary or object as a development utility, host or native on the desired platform/architecture.
The work is rather complete, I've managed to build asterisk, kismet and different X11/Xorg servers and all their dependencies.
I haven't begun on slimming down the stage outfits into something suitable for embedded flashing and packaging.
https://www.youtube.com/watch?v=BE9CXWV1alg
- Michael.