Cross platform building best practices (building 6 on 7)

[Garrett Cooper]

On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack <pisymbol at gmail.com> wrote:
> Hello Folks:
>
> I've done a lot of Googling and scouring the lists about this
> particular subject so I apologize for rehashing it.  However, I'm
> still confused on what's the best way to perform BSD cross platform
> builds.  Ideally what I want to have is an environment whereby I can
> build a 6.1-RELEASE tree on a 7.0-RELEASE box.  I thought originally I
> could check out a 6.1 release version, perform make world, and then
> use the output of that build as either a basis for a jail or a
> toolchain.  However, as noted by previous threads, 6.x doesn't build
> on a 7.x due to gcc4/binutils compatibility issues (please correct me
> if I'm wrong).  I then thought I could potentially download a patched
> binutils, copy it into src/contrib/binutils and that would potentially
> fix it.  No dice (and I'm still debugging why since this binutils
> package DOES build outside of the make world infrastructure without
> issue, this very well could be pilot error on my part since I didn't
> update the VERSION string and didn't trim the source files as per the
> FreeBSD-deleteList etc.).
>
> I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could
> complie a 6.x on a 7.x machine.  Well I haven't done that yet since at
> this point I believe I'm diverged from the path of FreeBSD build
> enlightenment!  Moreover, if would be NICE if I could bootstrap the
> normal dev tools from the exiting make world build tree.  I'm not yet
> ready for a lot of hackery on the build tree without asking around.
> :D!
>
> Does anyone due cross-platform builds (without host virtualization)?
>
> Thanks!
>
> -aps

(I'll stick to just hackers@ because I don't want to pollute
questions@ unnecessarily)

You touched on an important point. There were some code quality issues
(I think) with 6.x that were resolved moving to 7.x, which caused
gcc-4.2.x to barf.

gcc-4.2.x requires a newer version of binutils, just because (for API
/ usage compatibility).

What you should probably do is create a jail then do your development
for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...)
do 8.x development in yet a third. Jail's are a much better way to
isolate things such that you don't have to worry about toolchain
issues like these and are able to setup a sourcebase as the devs
intended it (for the most part; you may run into issues with sysctls
and virtual kernel stuff like that, but cest la vie... there isn't a
better way I know of than that outside of running a VM).

-Garrett