gmane.comp.gnu.coreutils.announce

Jim Meyering | 23 Oct 01:08

coreutils-6.4 released (stable)

Coreutils version 6.4 has been released.

If you haven't heard about the GNU coreutils, the FAQ is a good
place to start: <http://www.gnu.org/software/coreutils/faq/>.

This is a stable release.
Changes since 6.3 have been solely to fix bugs and to improve
portability and robustness.

A summary of the user-visible changes since 6.3 is included below.
For older changes see the distributed NEWS file, or this link:
  <http://cvs.savannah.gnu.org/viewcvs/coreutils/coreutils/NEWS?view=markup>

See the "How can you help?" section below.

Administrivia:
Coreutils is now using git for primary version control on the trunk and
future branches.  In the unlikely event that there is ever any more work
done on the 5.9x branch, it'll be done using the CVS repository.

All change sets are mirrored to an otherwise-read-only CVS repository
which is still being synchronized regularly to the repository on
savannah.gnu.org.  Thus, people tracking development can still follow
it via CVS.  Once the git repository is public, I'll announce it.

Thanks to everyone who has contributed either directly or via gnulib.
This release includes several portability fixes affecting coreutils
programs via parts of gnulib.  For details on those, see gnulib's
ChangeLog file, and/or the mailing list archives.

(Continue reading)

Matthew Woehlke wrote: > Paul Eggert wrote: >> [snip] >> Perhaps if you get some free time you can write down the exact story >> along those lines. > > Yup. Let me try this with Eric's m4 1.4.8 candidate and get back to you. > I'll also re-post your patch (adjusted) if I have to hack on it again. Ok. Using the latest snapshot Eric provided me with, m4 fails to build on Tandem NSK/OSS. Using the above, *plus* this patch: http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00140.html both 'make' and 'make check' succeed. ...and I finally figured out the problem is a simple '-l' (i.e. the amount of whitespace in the patch differs from the sources I have). With 'patch -l' I was able to apply the above patch as-is. (Or at least, the copy of it that I had laying around that I sure don't recall changing, other than to strip the m4 changes. I am now wondering if something went amiss in my copy-pasting that it wasn't working right off.) Is that more helpful (I hope!)? :-)

-- -- Matthew "Inches: An antiquated measurement unit still in use in certain backwards countries with incredibly low-cost computer equipment." -- groff documentation

I didn't see this show up on bug-gnulib, nor in the list queue, so I took the liberty of resending it... -------- Original Message -------- Subject: Re: coreutils-6.4 released (stable) Date: Wed, 15 Nov 2006 19:13:36 -0600 From: Matthew Woehlke <mw_triad AT users.sourceforge.net> To: bug-m4 AT gnu.org CC: bug-coreutils AT gnu.org, bug-gnulib AT gnu.org Matthew Woehlke wrote: > Paul Eggert wrote: >> [snip] >> Perhaps if you get some free time you can write down the exact story >> along those lines. > > Yup. Let me try this with Eric's m4 1.4.8 candidate and get back to you. > I'll also re-post your patch (adjusted) if I have to hack on it again. Ok. Using the latest snapshot Eric provided me with, m4 fails to build on Tandem NSK/OSS. Using the above, *plus* this patch: http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00140.html both 'make' and 'make check' succeed. ...and I finally figured out the problem is a simple '-l' (i.e. the amount of whitespace in the patch differs from the sources I have). With 'patch -l' I was able to apply the above patch as-is. (Or at least, the copy of it that I had laying around that I sure don't recall changing, other than to strip the m4 changes. I am now wondering if something went

Eric Blake <ebb9 <at> byu.net> writes: > I didn't see this show up on bug-gnulib, nor in the list queue, so I took > the liberty of resending it... > > -------- Original Message -------- > Date: Wed, 15 Nov 2006 19:13:36 -0600 > From: Matthew Woehlke <mw_triad AT users.sourceforge.net> > ... > Ok. Using the latest snapshot Eric provided me with, m4 fails to build > on Tandem NSK/OSS. Using the above, *plus* this patch: > http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00140.html > both 'make' and 'make check' succeed. As Bruno mentioned in <http://lists.gnu.org/archive/html/bug-gnulib/2006-11/msg00092.html>, he'd rather not head down this path due to the high cost/benefit ratio. Even if M4 builds with the abovementioned patch, the approach will likely cause runtime misbehaviors -- almost certainly in coreutils, and quite possibly also in M4. Perhaps there's a better way. In <http://lists.gnu.org/archive/html/bug-coreutils/2006-11/msg00069.html> I asked Matthew Woehlke why the patch was actually needed -- as it's not 100% clear to me -- and that hasn't been followed up on yet.

According to Paul Eggert on 11/16/2006 11:02 PM: >> Ok. Using the latest snapshot Eric provided me with, m4 fails to build >> on Tandem NSK/OSS. Using the above, *plus* this patch: >> http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00140.html >> both 'make' and 'make check' succeed. > > As Bruno mentioned in > <http://lists.gnu.org/archive/html/bug-gnulib/2006-11/msg00092.html>, > he'd rather not head down this path due to the high cost/benefit > ratio. Even if M4 builds with the abovementioned patch, the approach > will likely cause runtime misbehaviors -- almost certainly in > coreutils, and quite possibly also in M4. > > Perhaps there's a better way. In > <http://lists.gnu.org/archive/html/bug-coreutils/2006-11/msg00069.html> > I asked Matthew Woehlke why the patch was actually needed -- as it's > not 100% clear to me -- and that hasn't been followed up on yet. How about the following alternative - at configure time, if there is a mismatch between sizeof(uintmax_t) and sizeof(intmax_t), we redefine these two types to be the same size as the smaller of the two (effectively disabling long long on Tandem NSK since there is no counterpart unsigned long long). In other words, rather than trying to deal with the 64-bit/32-bit mismatch, is there a clean way to detect that NSK has broken 64-bit types (broken in the sense that there is not symmetric support) and avoid them altogether? Matt, can you refresh my memory - does NSK actually provide uintmax_t and intmax_t? Or does it just provide long long, where the gnulib configure

According to Paul Eggert on 11/17/2006 10:55 AM: > Currently, though, I think the proposed solution is 'just compile with > -O on old NSK'. If you compile with -O, long long int has a bug that > 'configure' will detect (assuming latest CVS), and it won't define > HAVE_LONG_LONG_INT. That should be good enough to get things to work > on that platform, albeit only with 32-bit types. The lack of 64-bit types should not matter for m4 1.4.8, since it does not use anything bigger than 'long int' outside of gnulib modules (CVS head, on the other hand, will use u/intmax_t in more places). So I am going ahead and releasing m4 1.4.8, even though it will miscompile on old NSK with -O omitted, rather than waiting for any other changes in gnulib. It is a small enough audience that the few people that compile on that platform should be able to figure out from mailing list archives how to make compilation work, without too much effort. -- Life is short - so eat dessert first! Eric Blake ebb9 <at> byu.net

Matthew, Paul Eggert wrote: > Eric Blake <ebb9 <at> byu.net> writes: > > > I didn't see this show up on bug-gnulib, nor in the list queue, so I took > > the liberty of resending it... > > > > -------- Original Message -------- > > Date: Wed, 15 Nov 2006 19:13:36 -0600 > > From: Matthew Woehlke <mw_triad AT users.sourceforge.net> > > ... > > Ok. Using the latest snapshot Eric provided me with, m4 fails to build > > on Tandem NSK/OSS. Using the above, *plus* this patch: > > http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00140.html > > both 'make' and 'make check' succeed. > > As Bruno mentioned in > <http://lists.gnu.org/archive/html/bug-gnulib/2006-11/msg00092.html>, > he'd rather not head down this path due to the high cost/benefit > ratio. Even if M4 builds with the abovementioned patch, the approach > will likely cause runtime misbehaviors -- almost certainly in > coreutils, and quite possibly also in M4. Yes. Matthew, I suggest that you compile with optimization (CFLAGS="-O" or something like that). Then, with the patch to m4/longlong.m4 that Paul committed on 2006-11-07, the configure script should find that 'long long' is unusable and refrain from using it. You can verify if this is so by looking whether HAVE_LONG_LONG_INT gets defined in config.h.