bug#20713: aclocal/tar.m4 and solaris 5.10
Hi Dagobert - thanks. I'm aware of /usr/xpg4/bin. But automake should at least not fail unexpectedly, hence my report. I think Mike's patch will suffice. --cheers, karl.
bug#20713: aclocal/tar.m4 and solaris 5.10
Hi Karl, Am 01.06.2015 um 23:02 schrieb Karl Berry : > Running a configure script on solaris 5.10 generated with automake-1.15, > I got these errors about id, which being pre-POSIX, does not support -u: > > id: illegal option -- u > Usage: id [-ap] [user] > id: illegal option -- g > Usage: id [-ap] [user] > checking whether UID 'unknown' is supported by ustar format... > ./configure: line 4190: test: unknown: integer expression expected > no > checking whether GID 'unknown' is supported by ustar format... > ./configure: line 4200: test: unknown: integer expression expected > no This is a long-standing issue on Solaris and the fix I use is prepending /usr/xpg4/bin to PATH as there are multiple versions of id installed by default as documented in id(1m). Best regards — Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896
bug#20713: aclocal/tar.m4 and solaris 5.10
if we can only test tools during configure, and the dist step requires results from that probing ... Fair enough. Patch is fine on that basis. --thanks, karl.
bug#20713: aclocal/tar.m4 and solaris 5.10
On 22 Feb 2022 16:29, Karl Berry wrote: > The "test" item, most of the way down in the "Limitations of Shell > Builtins" node of the Autoconf manual, reports a lot of the things that > have led to the common forms/workarounds. > https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Builtins.html#Limitations-of-Builtins thanks, this is what i was looking for. maybe i should actually read the autotools manuals one day instead of using them purely as references. > the reason your system hit this code path > > I was not running make dist. I was just running configure on Solaris 5.10. > As far as I can recall. i'm sure that was the case (i.e. you ran configure but never dist). but if we can only test tools during configure, and the dist step requires results from that probing, but we're not allowed to probe dist-specific tools during configure, then we're in a bit of a catch-22. i'm not aware of other parts being delayed/split based on their usage. for example, if i just `make && make install`, one could argue that configure checking for deps/behaviors that only matter to `make check` are incorrect. off the top of my head, i think Automake's `missing` tool is about the only exception to this approach/rule, and even then, that's pretty thin -- it's only seeing if a specific program exists, not whether it supports specific functionality or is otherwise buggy. >it can be helpful when you're hacking on a system and want to pull >the state back out. > > Personally, I would never trust make dist not to alter the state > that it was supposedly snapshotting. to be clear, when i said "state", i meant "the source code". obviously i wouldn't expect (or want) `make dist` to pick up any intermediates or build outputs. i'm not sure along what lines your distrust of dist flows, but i will point out that this logic is entirely Automake's, so it would be a little unusable if you consider `make dist` unreliable as a maintainer of Automake :). -mike signature.asc Description: PGP signature
bug#20713: aclocal/tar.m4 and solaris 5.10
i have no idea what the quoting style/preference is in the GNU world, Nothing GNU-wide, but among autotools and related packages written/maintained by approximately the same group of people, I believe test x"$foo" = x1 is the most-usual style. Though "x$foo" is common too, since it makes no difference. The "test" item, most of the way down in the "Limitations of Shell Builtins" node of the Autoconf manual, reports a lot of the things that have led to the common forms/workarounds. https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Builtins.html#Limitations-of-Builtins Not including the not-quoting of constant strings though, granted, since that also makes no difference. I can't recall any other style guide for shell coding conventions, either. Anyway, back to the bug topic. i think there's merit to issuing a warning Ok, I yield. No appetite to argue further over this tiny issue. configure user can (re)create dist tarballs too. not the common flow, Quite an understatement there :). the reason your system hit this code path I was not running make dist. I was just running configure on Solaris 5.10. As far as I can recall. it can be helpful when you're hacking on a system and want to pull the state back out. Personally, I would never trust make dist not to alter the state that it was supposedly snapshotting. But whatever. --thanks, karl.
bug#20713: aclocal/tar.m4 and solaris 5.10
On 21 Feb 2022 16:26, Karl Berry wrote: > should we change "unknown" to $GID & $UID respectively ? > > I guess it couldn't hurt, although I doubt it makes any difference in > practice. i feel like you just accidentally wrote Automake's motto :p > if test $am_uid = "unknown"; then > > Don't we usually avoid quoting constant strings? I.e.: > if test "$am_uid" = unknown; then tbh, i have no idea what the quoting style/preference is in the GNU world, if there actually is one. i know i see plenty of underquoting, and plenty of odd `test` styles that aren't well documented (like using the "x" prefix to avoid testing empty strings). > AC_MSG_WARN([ancient id detected; assuming current UID is ok, but > dist-ustar might not work]) > > "Might"? Either it works or it doesn't? Anyway, who ever uses ustar? > Never seen it. we won't know whether it works until we actually try to create an archive. and depending on the system, that might be too late (see below). > Anyway, seems like such a warning "might" be useful when producing an > archive with automake (running make dist), but not when running > configure. When merely doing "./configure && make", ustar is irrelevant. sure, but we don't probe tools during `make dist`, we do it during configure > Anyway #2, I think the chances of someone wanting to produce a ustar > archive on a system with old id is zero. > > Thus I suggest just fixing the syntax stuff and letting it go at that. ustar might not be the most common nowadays. i think there's merit to issuing a warning so we aren't in the situation of people reporting bugs that `make dist` threw a weird error they don't understand, and if their system was in such a bad state, why weren't they warned about it ? in fact, isn't that what led to these checks in the first place ? we have reports from users: https://bugs.gnu.org/8343 https://bugs.gnu.org/13588 > the point of the checks isn't just to annoy the user. > > No :)? That's what it seems like. Helpful to the package developer; > annoyance to the configure user. -k configure user can (re)create dist tarballs too. not the common flow, but it can be helpful when you're hacking on a system and want to pull the state back out. or when trying to comply with the GPL requirements :). the reason your system hit this code path is because it wasn't able to handle the formats earlier in the list (gnutar in this case). -mike signature.asc Description: PGP signature
bug#20713: aclocal/tar.m4 and solaris 5.10
should we change "unknown" to $GID & $UID respectively ? I guess it couldn't hurt, although I doubt it makes any difference in practice. if test $am_uid = "unknown"; then Don't we usually avoid quoting constant strings? I.e.: if test "$am_uid" = unknown; then AC_MSG_WARN([ancient id detected; assuming current UID is ok, but dist-ustar might not work]) "Might"? Either it works or it doesn't? Anyway, who ever uses ustar? Never seen it. Anyway, seems like such a warning "might" be useful when producing an archive with automake (running make dist), but not when running configure. When merely doing "./configure && make", ustar is irrelevant. Anyway #2, I think the chances of someone wanting to produce a ustar archive on a system with old id is zero. Thus I suggest just fixing the syntax stuff and letting it go at that. the point of the checks isn't just to annoy the user. No :)? That's what it seems like. Helpful to the package developer; annoyance to the configure user. -k
bug#20713: aclocal/tar.m4 and solaris 5.10
On Mon, 01 Jun 2015 21:02:32 +, Karl Berry wrote: > Running a configure script on solaris 5.10 generated with automake-1.15, > I got these errors about id, which being pre-POSIX, does not support -u: > > id: illegal option -- u > Usage: id [-ap] [user] > id: illegal option -- g > Usage: id [-ap] [user] > checking whether UID 'unknown' is supported by ustar format... > ./configure: line 4190: test: unknown: integer expression expected > no > checking whether GID 'unknown' is supported by ustar format... > ./configure: line 4200: test: unknown: integer expression expected > no > > It comes from aclocal-1.15/tar.m4, which says: > ... Errors in the 'id' calls > # below are definitely unexpected, so allow the users to see them > > Well, they are not "unexpected" on this system, so it's not especially > helpful to see them. Still, I suppose it is not worth worrying about. > And I'm sure it is not worth parsing the output of this old id (with no > args passed) to get the info, but for the record, that would be: > uid=1053(karl) gid=1053(karl) > > But what I do think would make sense is to avoid the subsequent error of > using a numeric test expression on a known non-numeric (the string > "unknown") when id fails. After all, that much is tar.m4's own doing. > Perhaps simply change > if test $am_uid -le $am_max_uid; then > to > if test $am_uid != unknown && test $am_uid -le $am_max_uid; then > (and ditto gid). should we change "unknown" to $GID & $UID respectively ? if the `id` call fails, seems like we could at least still issue a warning. the point of the checks isn't just to annoy the user. if test $am_uid = "unknown"; then AC_MSG_WARN([ancient id detected; assuming current UID is ok, but dist-ustar might not work]) elif test $am_uid -le $am_max_uid; then AC_MSG_RESULT([yes]) else AC_MSG_RESULT([no]) _am_tools=none fi -mike
bug#20713: aclocal/tar.m4 and solaris 5.10
Running a configure script on solaris 5.10 generated with automake-1.15, I got these errors about id, which being pre-POSIX, does not support -u: id: illegal option -- u Usage: id [-ap] [user] id: illegal option -- g Usage: id [-ap] [user] checking whether UID 'unknown' is supported by ustar format... ./configure: line 4190: test: unknown: integer expression expected no checking whether GID 'unknown' is supported by ustar format... ./configure: line 4200: test: unknown: integer expression expected no It comes from aclocal-1.15/tar.m4, which says: ... Errors in the 'id' calls # below are definitely unexpected, so allow the users to see them Well, they are not "unexpected" on this system, so it's not especially helpful to see them. Still, I suppose it is not worth worrying about. And I'm sure it is not worth parsing the output of this old id (with no args passed) to get the info, but for the record, that would be: uid=1053(karl) gid=1053(karl) But what I do think would make sense is to avoid the subsequent error of using a numeric test expression on a known non-numeric (the string "unknown") when id fails. After all, that much is tar.m4's own doing. Perhaps simply change if test $am_uid -le $am_max_uid; then to if test $am_uid != unknown && test $am_uid -le $am_max_uid; then (and ditto gid). Clearly nothing critical. Just reporting ... Best, Karl
