Poky makes various assumptions about "tar" being GNU tar. There is no way to override the location of tar (e.g. TAR=gtar) for distros that use a different default "tar". I've had successful builds with libarchive tar by skipping the check in sanity.bbclass, replacing cmd = "tar --xattrs --xattrs-include='*' -cf - -S -C %s -p . | tar --xattrs --xattrs-include='*' -xf - -C %s" % (src, dst) in poky/meta/lib/oe/path.py with cmd = "tar c --xattrs -f - -S -C %s -p . | tar x --xattrs -f - -C %s" % (src, dst) and replacing (in the same file) cmd = "cd %s; find . -type d -print | tar --xattrs --xattrs-include='*' -cf - -S -C %s -p --no-recursion --files-from - | tar --xattrs --xattrs-include='*' -xhf - -C %s" % (src, src, dst) with cmd = "cd %s; find . -type d -print | tar c --xattrs -f - -S -C %s -p --no-recursion --files-from - | tar x --xattrs -f - -C %s" % (src, src, dst) Not sure if there's any unwanted side effects from using libarchive tar -- so not sure if this should be fixed the way I've described (with a check for which tar implementation is being used) or simply with a check for different tar implementations instead of hardcoding that "tar" is the one to use. All distros I've checked that use a different implementation as their default tar have GNU tar available in their repositories as well (by another name, typically gtar).
If you change the "tar" link created in HOSTTOOLS to point at gtar it would probably resolve this. Not sure how to do that cleanly but we could document it and suggest it to people with this issue. Which distros is this an issue on?
We may just document this limitation or add a sanity check and refuse to continue unless tar is gtar.