Thanks Raul and Giacomo. Let me see if I can summarize the final solution: to add 'tar-pax' to 'AM_INIT_AUTOMAKE'. But we are worried that the host 'tar' may not support 'pax', right?

If so, the configure script is ultimately just a shell script and this (if the user ID is larger than 2 million, and if available 'tar' supports pax) is a pretty easy thing to check in a shell script. We can place the 'AM_INIT_AUTOMAKE' in such a conditional statement with these two checks so it automatically adds 'pax' when it is needed and not make any changes if it is not needed.

This will keep technical (source-code related) things behind the scenes and not annoy ourselves (when you change 'configure.ac' and not commit it, the ultimate Gnuastro version will have a '-dirty' suffix!) or future readers ;-).

Can you add that conditional in 'configure.ac' and test that it works properly on a macOS and GNU/Linux? I will then test it on my GNU/Linux and merge it.

Checked on Raul's computer, apparently the latest workaround doesn't work, and for two reasons:

• TAR_OPTIONS are not recognized (neither on a setup with gnu bash, gnu make, gnu tar!)
• setting --owner=root requires extra perms

That means that my attempt is not portable, and that even --owner=root may have portability issues.

Thanks Mohammad.

Unfortunately the "fastest solution" won't work either: on gnutar -o is also an alias for --old-archive, that is '--format=v7'. Incidentally, this also mean that we aren't using the same format, apparently.
Here is branch that forces the same format (ustar, as per convo in Maneage), regardless of the tar used: https://gitlab.cefca.es/glorenzetti/gnuastro/-/commit/b9f950d79fa1a64468b99f9b9be770461c5c702e
(Note: this doesn't fix Raul's issue, it's just for homogeneous reasons)

Speaking of the issue, let me stress what triggered it: the output of 'id -u' and 'id -g' on Raul's computer is O(10⁹), while on a typical Linux the result is O(10³) (usually both start from 1000, adding +1 for a new user, unless different settings). Testing on personal MacOSes, the result is ~500.
To have userIDs that big is strange, and even the comment in the autogenerated aclocal.m4 is along the same lines:

>     [# The POSIX 1988 'ustar' format is defined with fixed-size fields.
>      # There is notably a 21 bits limit for the UID and the GID.  In fact,
>      # the 'pax' utility can hang on bigger UID/GID (see automake bug #8343
>      # and bug #13588).
>      am_max_uid=2097151 # 2^21 - 1
>      am_max_gid=$am_max_uid
>      # The $UID and $GID variables are not portable, so we need to resort
>      # to the POSIX-mandated id(1) utility.  Errors in the 'id' calls
>      # below are definitely unexpected, so allow the users to see them
>      # (that is, avoid stderr redirection).

I'm investigating why those numbers are that big.

Rearding the usage of userIDs in the metadata, the idea is interesting and will probably solve also the issue (I guess that tar wouldn't crash if it avoids reading IDs...). The issue is then how to put those in automake, I'm looking into it.

Apparently bsdtar -o (and we use -chof...) is the same as
'--old-archive', i.e. '--format=ustar'. ustar is among those who
doesn't support ids grater than ~2M (see
https://www.gnu.org/software/tar/manual/html_chapter/Formats.html).
We can force tar to use something more recent, such as pax, as showed in this branch: https://gitlab.cefca.es/glorenzetti/gnuastro/-/commit/7bfcdd9f91b971fb6234f0a6fc06aef69811df17

Is this a desired change? Apparently not, GNU suggests to keep the old one, due to compatibilty issues: https://www.gnu.org/software/automake/manual/1.10/html_node/Options.html#index-Option_002c-tar_002dv7

On the other hand, the values of 'id -u' and 'id -g' on your computer appear too big, that I'm unable to replicate on a personal macOS (I obtain something around ~500, instead of ~1 billion).
Perhaps is worth investigating why those IDs have those values, if it's due to a initial configuration of the computer.