# Building a version of FreeBSD which is different to that running on the host



## balanga (Apr 19, 2019)

Should I expect to be able to build say, FreeBSD 11.2-RELEASE from its src by running `make buildworld` on FreeBSD 12.0-RELEASE or do I need to create an 11.2 jail for the purpose?

I hadn't thought of using a jail previously...


----------



## T-Daemon (Apr 19, 2019)

A_Brief_Guide_To_Cross_Compiling_FreeBSD

release(7)

```
_TARGET_          The target machine type for cross-building a release.

_TARGET___ARCH_      The target machine architecture for cross-building a
              release.

              For the supported    list of    _TARGET_ and _TARGET___ARCH_ combi-
              nations, consult the output of ``make targets'' as docu-
              mented in    build(7).
```


----------



## SirDice (Apr 19, 2019)

TARGET and TARGET_ARCH are more for building a i386 version on AMD64 for example. Or ARM on AMD64. That sort of thing. 

Building world is fairly self-contained. So it's perfectly fine to build any version on any other version. Most of the time. I wouldn't try to build a 12.0-RELEASE on 6.3-RELEASE for example but building a 11.2-RELEASE on a 12.0-RELEASE machine shouldn't be a problem. I've done this myself countless times.


----------



## balanga (Apr 19, 2019)

SirDice said:


> TARGET and TARGET_ARCH are more for building a i386 version on AMD64 for example. Or ARM on AMD64. That sort of thing.
> 
> Building world is fairly self-contained. So it's perfectly fine to build any version on any other version. Most of the time. I wouldn't try to build a 12.0-RELEASE on 6.3-RELEASE for example but building a 11.2-RELEASE on a 12.0-RELEASE machine shouldn't be a problem. I've done this myself countless times.



I've been trying to build various releases under 12.0 but had a problem with 11.0 when I hit this error:-

```
--- all_subdir_usr.bin ---
cc  -O -pipe   -D__REGEX_PRIVATE -I/usr/src/usr.bin/vi -I/usr/src/usr.bin/vi/../../contrib/nvi -I/usr/src/usr.bin/vi/../../contrib/nvi/regex -DUSE_WIDECHAR -DUSE_ICONV -
--- all_subdir_usr.sbin ---
RPCGEN_CPP=cpp\  rpcgen -c -C -DWANT_NFS3 /usr/obj/arm.arm/usr/src/tmp/usr/include/rpcsvc/nfs_prot.x -o nfs_prot_x.c
--- all_subdir_usr.bin ---
--- all_subdir_usr.bin/xlint ---
===> usr.bin/xlint/llib (all)
--- all_subdir_lib ---
--- Kyuafile ---
--- all_subdir_usr.bin ---
--- llib-lposix.ln ---
lint -cghapbx -Cposix /usr/src/usr.bin/xlint/llib/llib-lposix
sh: lint: not found
*** [llib-lposix.ln] Error code 127
```

then it struck me that 12.0 may not include various programs required for the build. ie `lint`, so now I'm looking at creating an 11.0 jail in which to build 11.0.

Does that make sense?


----------



## T-Daemon (Apr 19, 2019)

balanga said:


> then it struck me that 12.0 may not include various programs required for the build. ie  lint


I stumbled over this mailing list post concerning *lint*. You might give it a try before continuing setting up a jail:

more fallout from removal of lint


> Since lint was removed from 12.0-CURRENT, it is not possible to build
> 11.1-STABLE on a 12.0-CURRENT host, but I was able to work around that
> by copying /usr/bin/true to /usr/bin/lint.


----------



## balanga (Apr 19, 2019)

T-Daemon said:


> I stumbled over this mailing list post concerning *lint*. You might give it a try before continuing setting up a jail:
> more fallout from removal of lint



I've already set up an 11.0 jail so do have access to `lint`. It's probably safer to create the correct environment when building versions of FreeBSD which are different from that on the host, since there could be other such unforeseen gotchas waiting.


----------



## PMc (Apr 22, 2019)

balanga said:


> I've already set up an 11.0 jail so do have access to `lint`. It's probably safer to create the correct environment when building versions of FreeBSD which are different from that on the host, since there could be other such unforeseen gotchas waiting.



There used to be a recommendation that after such a build completes, one should build again on the newly built version itself.
That may be a waste of time in many cases, but nevertheless I consider it good advice.


----------

