Red Hat Bugzilla – Bug 843376
configure stops when run by big UID
Last modified: 2013-06-16 02:11:40 EDT
Description of problem:
When running a configure (autoconf) with a uid higher then 21 bits (i.e winbind) pax will hang forever.
This is very clear when trying to build a cross compiler and PPL lib.
Version-Release number of selected component (if applicable):
Create an user with uid bigger then 21 bit (for example 16777216) and run configure on PPL.
Steps to Reproduce:
1. Create test user with id > 21 bits
2. Run configure on PPL version 0.11.2 (example)
Configure hangs with message:
ATTENTION! pax archive volume change required.
Ready for archive volume: 1
Input archive name or "." to quit pax.
Archive name >
Configure will exit (successfully or unsuccessfully)
Bug filed att GNU on this with bug#8343: hangs the whole configure script
Hello Thomas, thanks for your report!
This is because the line in configure.ac:
> AM_INIT_AUTOMAKE([... tar-ustar ...])
And the ustar format of tar archive is designed to store at most uids of 21
I'm not sure if pax is the correct component to address this bug. It seems
that this should be switched to 'autoconf'. I have tried pax with big-uid
$ echo $UID
$ echo "content" > FILE
$ pax -w -f file.tar FILE
pax: Ustar header field is too small for FILE
[bignum@raiskup testoftar]$ echo $?
And 'pax' is throwing *correctly* the return value 1. So the configure script
should probably at least take this error output into account and fail.
I'll switch this bug to autoconf but feel free to re-switch it to pax if you
feel it is the correct target.
Side notes (when asking for ustar format):
- distributed pax fails correctly on 'ustar' (retval = 1)
- gnu tar correctly fails
- star "succeeds" but it trims UID at 21 bits
Btw., when the pax utility is not present on the system, gnu tar is used on
Fedora by configure script and the configure script succeeds (even if gnu tar
fails on big uids).
The correct way how to deal with big uids is probably to use 'pax' (newer
posix) format that is not yet correctly supported by GNU tar.
This bug is relevant to automake.
Patch was send to upstream.
This bug is reassigned to automake
How to test:
description is mentioned in Steps to Reproduce:
scm-commit (http://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20130429/1009087.html) -> CLOSED RAWHIDE
Thanks for backporting!
Some links for history observers:
~> continued ..
automake-1.13.2-1.fc19 has been submitted as an update for Fedora 19.
automake-1.13.2-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.