GNU bug report logs - #13912
Feedback on coreutils 8.13

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13912 in the body.
You can then email your comments to 13912 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Ellis N. Thomas" <ExtraLeveLInSoftware <at> ntlworld.com>
To: bug-coreutils <at> gnu.org
Subject: Feedback on coreutils 8.13
Date: Sat, 9 Mar 2013 16:22:52 +0000

        Notes on installation of coreutils 8.13

To: <bug-coreutils <at> gnu.org>

1. Introduction

	The purpose of this feedback is to notify some difficulties encountered
with coreutils.  As explained below, the release used was NOT the  
latest, so it
is quite likely that these matters have been previously addressed.  On  
the other
hand, it is possible that installation has not been attempted for this  
actual
Unix version.

	In trying to obtain the latest Ada compiler from Gnu, there had
previously been some initial problems concerning missing facilities in  
the Unix
version on this iMac.  Running Mac OS X:

System Version:	Mac OS X 10.5.8 (9L30)
Kernel Version:	Darwin 9.8.0
>uname -mpv
Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;  
root:xnu-1228.15.4~1/RELEASE_I386 i386 i386

	The download of gcc-4.7.2 made in Feb-2013 included a file MD5SUMS to
verify the correct transfer of the files.  However, the suggested  
usage of
md5sum failed as this command was not available!  Investigation on the  
Gnu
website showed that this is available in coreutils, but there seemed  
to be no
way of downloading this alone, so downloaded version 8.21 from the ftp  
area
(ftp://ftp.gnu.org/gnu/coreutils/).  However, these are xz versions  
and there
seems to be no support for that format on this machine.  The latest gz  
was 8.13
from Sep 2011, so also downloaded version 8.13, and proceeded trying  
to install this.

	This feedback concerns the following points.

  - Incomplete information provided in the INSTALL plus README files

  - Some problems with configure

  - An error reported by make check.

  - No test failure as reported in README for Mac OS X 10.5.1 (Darwin  
9.1).

	The information is supplied in the hope that it might be useful to
developers.


2. Information in the INSTALL plus README files

	Referred to coreutils-8.13/INSTALL and coreutils-8.13/README.  Because
only md5sum was required, tried to establish how to obtain this alone.

	In the INSTALL it says:

**** From INSTALL ****
   Some packages pay attention to `--enable-FEATURE' options to
`configure', where FEATURE indicates an optional part of the package.
They may also pay attention to `--with-PACKAGE' options
**** End from INSTALL ****

and it also says:

**** From INSTALL ****
The `README' should mention any `--enable-' and `--with-' options that  
the
package recognizes.
**** End from INSTALL ****

	However, the README does NOT clarify this.

	From the configure --help, it was established that there is also
a --without-PACKAGE option.

	Initially tried ./configure --enable-md5sum but this gave

configure: WARNING: unrecognized options: --enable-md5sum

and proceeded anyway.

	When `make' was run, many errors were reported, concerning expr.c (see
next section).  Since these concern the expr command which was not  
really
needed, tried repeating ./configure using  --without-PACKAGE
./configure --without-expr

Ran, but gave:

configure: WARNING: unrecognized options: --without-expr

	It would help if the README covered the options that actually apply
(see also next section).


3. Some problems with configure

	Retried make, redirecting the output to a log file.  The errors in expr
were more extensive than realised before.  The first error is
expr.c:54:18: error: gmp.h: No such file or directory

	It seems that configure has made an incorrect decision about the
availability of gmp, which is not available (but is placed ready to be  
installed
along with the gcc sources. It had previously been established that it  
was a
Prerequisite).

	Noted that config.status has
D["HAVE_GMP"]=" 1"
and the expr.c source tests this.  It seems that configure has
incorrectly decided that gmp is available, and expr.c fails to find  
the header,
and all other errors arise from this.

	Since the expr.c source allowed for the test failing, it seemed  
possible
to proceed without gmp.  So config.status was modified so that
D["HAVE_GMP"]=" 0"

	Reran make, redirecting the output to a log file.  This ran OK.

	It was only later that it was realised that configure --help included:

**** From --help ****
  --without-gmp           do not use the GNU MP library for arbitrary
                          precision calculation (default: use it if  
available)
**** End from --help ****


	The optional nature of gmp and this option ought to be included in the
README.  However, the decision made by configure "use it if available"  
still
seems incorrect.


4. An error reported by make check.

	Tried `make check'.  Ran to completion, recording one failure
FAIL: install/install-C
There was also a log in tests/test-suite.log, but it seemed to be  
removed later
by make clean.

	The `make installcheck' has not been done.  If it is of help to you,
then this can be done, or partially done, to identify the exact failure.


5. Test failure reported in README

	There is a test failure in 'make check' reported in README concerning
Mac OS X 10.5.1 (Darwin 9.1).  This concerns ACL support, and suggests  
using
--disable-acl.

	This machine has Mac OS X 10.5.8 (Darwin 9.8.0).  The 'make check' was
performed without having done --disable-acl, but the "numerous  
failures" stated
did not arise, although there was one error (see previous section).   
The tests
were done as a normal user (not root), but having the privilege to use  
sudo (not
used at this point).

	The different effect for this Mac version might or might not be of
relevance to Gnu developers!


6. Summary

	This report applies to an old version of coreutils, 8.13.  The  
following
points were observed - more details above.

  - Incomplete information provided in the INSTALL plus README files

  - Some problems with configure

  - An error reported by make check.

  - No test failure as reported in README for Mac OS X 10.5.1 (Darwin  
9.1).

	In addition, the reason for using coreutils 8.1, was that version 8.21
had only are xz versions of the files and there seems to be no support  
for that
format on this machine.  It would help if the Gnu website had further
information about handling xz, or continued to support gz.  For  
example, when
gcc was downloaded as gcc-4.7.2, this still provided gz versions.

	Further, it would help if it was possible to select specific parts of
coreutils, and the README described how to do this.  On an existing  
Unix system,
like Darwin, many of these programs are already available

	If extra information about the matters reported above would be of value
please contact:
	ExtraLeveLInSoftware <at> ntlworld.com

Ellis N. Thomas/ 9-Mar-2013

Message #8 received at 13912 <at> debbugs.gnu.org (full text, mbox):

From: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
To: ExtraLeveLInSoftware <at> ntlworld.com (Ellis N. Thomas)
Cc: 13912 <at> debbugs.gnu.org
Subject: Re: bug#13912: Feedback on coreutils 8.13
Date: Sat, 9 Mar 2013 17:38:07 -0500 (GMT+5)

Ellis N. Thomas writes:
> 
>          Notes on installation of coreutils 8.13

Thanks for writing up your experience. Even though it's mostly a series of
bad choices, they were choices that only an outsider would make, so they do
reveal things that the insiders haven't thought of.

> 
> System Version:	Mac OS X 10.5.8 (9L30)
> Kernel Version:	Darwin 9.8.0
>  >uname -mpv
> Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; 
> root:xnu-1228.15.4~1/RELEASE_I386 i386 i386
> 
> 	The download of gcc-4.7.2 made in Feb-2013 included a file MD5SUMS to
> verify the correct transfer of the files.  However, the suggested usage of
> md5sum failed as this command was not available!  Investigation on the Gnu

I found this surprising. I would have expected md5sum to be installed with
the OS. So I googled "md5sum macos" and the first result is a page with
installation instructions for a standalone package called "md5sha1sum". That
would probably be easier to install than coreutils, since it's much smaller.
I wonder how you managed to skip over it.

Not important though; compiling coreutils shouldn't be hard.

> website showed that this is available in coreutils, but there seemed to be
> no way of downloading this alone, so downloaded version 8.21 from the ftp
> area (ftp://ftp.gnu.org/gnu/coreutils/).  However, these are xz versions
> and there seems to be no support for that format on this machine.  The

This sounds very familiar to me. At one point I already had all these
compressor/decompressors installed:
  7zr
  bzip2
  compress
  gzip
  lzop
  p7zip
  zip
and coreutils decided to make YET ANOTHER ONE (xz) mandatory. "Compression
format of the week" is a frustrating game! So I completely understand your
decision that...

> latest gz was 8.13 from Sep 2011, so also downloaded version 8.13, and
> proceeded trying to install this.

...the only way to win is not to play. (If you did choose to play, googling
"macos xz" looks promising.)

Moving on:

> 
> **** From INSTALL ****
> The `README' should mention any `--enable-' and `--with-' options that the
> package recognizes.
> **** End from INSTALL ****
> 
> 	However, the README does NOT clarify this.

This is clearly a bug. INSTALL lies about the contents of README. I think
this should be fixed by modifying README to fulfill the promise. It's
possible to find the --with options in the output of configure --help but
having them in the README, with more verbose explanations, would be nice.

> 
> 	From the configure --help, it was established that there is also
> a --without-PACKAGE option.

The thing about configure --help is that it's too short. It's too short
because it's trying not to be too long (and somehow failing at that too).
Here's the section of configure --help from coreutils 8.13 (it's practically
identical to 8.21):

:Optional Packages:
:  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
:  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
:  --with-gnu-ld           assume the C compiler uses GNU ld default=no
:  --with-libiconv-prefix[=DIR]  search for libiconv in DIR/include and DIR/lib
:  --without-libiconv-prefix     don't search for libiconv in includedir and libdir
:  --with-libpth-prefix[=DIR]  search for libpth in DIR/include and DIR/lib
:  --without-libpth-prefix     don't search for libpth in includedir and libdir
:  --without-included-regex
:                          don't compile regex; this is the default on systems
:                          with recent-enough versions of the GNU C Library
:                          (use with caution on other systems).
:  --without-selinux       do not use SELinux, even on systems with SELinux
:  --with-packager         String identifying the packager of this software
:  --with-packager-version Packager-specific version information
:  --with-packager-bug-reports
:                          Packager info for bug reports (URL/e-mail/...)
:  --with-tty-group[=NAME]
:                          group used by system for TTYs, "tty" when not
:                          specified (default: do not rely on any group used
:                          for TTYs)
:  --without-gmp           do not use the GNU MP library for arbitrary
:                          precision calculation (default: use it if available)
:  --with-libintl-prefix[=DIR]  search for libintl in DIR/include and DIR/lib
:  --without-libintl-prefix     don't search for libintl in includedir and libdir

You've understood that the documentation of "--without-PACKAGE" is using the
all-caps PACKAGE as a metasyntactic variable, which you're supposed to
replace with the name of the package you want to do without. This wasn't
really explained but you figured it out anyway; congratulations on getting
that far.

The other unexplained thing, which you didn't figure out, is that the stuff
below the generic --with-PACKAGE and --without-PACKAGE lines, from
"--with-gnu-ld" to "--without-libintl-prefix", is the complete list of valid
PACKAGEs.

I don't know why the generic --with-PACKAGE and --without-PACKAGE lines are
included in the help output. Their presence seems to imply that the list of
valid values for PACKAGE is open-ended, but then you immediately get a
complete list. I think the help would be more helpful if those top 2 lines
were deleted.

The same goes for the enable/disable section. (I also think the distinction
between with/without and enable/disable is something that isn't helpful to
anyone but the people maintaining the autoconf scripts. If there was an upper
layer that made --enable an alias for --with and --disable an alias for
--without, the users would probably be grateful for it.)

So, the specific things you tried were wrong because:

> 
> 	Initially tried ./configure --enable-md5sum but this gave
> 
> configure: WARNING: unrecognized options: --enable-md5sum

md5sum isn't a feature you can enable/disable (--enable-FEATURE). The help
output lists them all.

> 
> and proceeded anyway.
> 
> 	When `make' was run, many errors were reported, concerning expr.c (see
> next section).  Since these concern the expr command which was not 
> really
> needed, tried repeating ./configure using  --without-PACKAGE
> ./configure --without-expr

expr isn't a package you can with/without (--without-PACKAGE). The help
output lists them all.

It's great that after all this trouble you've held on to your optimistic
belief that there must be some way of configuring just the program you want,
if only you can just find the right syntax. Sadly, it just isn't so.

Ideally, "make src/md5sum" or "make -C src md5sum" would work, but the
Makefiles in coreutils aren't quite good enough for it to work out of the
box. Some dependencies are missing. But if your first attempt got far enough
to blow up on expr.c, "make -C src md5sum" might actually work afterward.

> 3. Some problems with configure
> 
> 	Retried make, redirecting the output to a log file.  The errors in expr
> were more extensive than realised before.  The first error is
> expr.c:54:18: error: gmp.h: No such file or directory
> 
> 	It seems that configure has made an incorrect decision about the
> availability of gmp, which is not available (but is placed ready to be 
> installed along with the gcc sources. It had previously been established
> that it was a Prerequisite).
> 
> 	Noted that config.status has
> D["HAVE_GMP"]=" 1"

It sounds like configure found your not-yet-installed gmp and tried to use
it, with disastrous results. This is the part of the bug report where you
should include your config.log, so we can see exactly how that HAVE_GMP
became 1. And I won't be surprised if it turns out to be a bug that's already
fixed in 8.21.

> and the expr.c source tests this.  It seems that configure has
> incorrectly decided that gmp is available, and expr.c fails to find 
> the header,
> and all other errors arise from this.
> 
> 	Since the expr.c source allowed for the test failing, it seemed 
> possible
> to proceed without gmp.  So config.status was modified so that
> D["HAVE_GMP"]=" 0"

Editing a config.status by hand? That sure shows bravery and determination.

I'm quitting here. The rest of the story needs to be read by someone who
actually knows MacOS.

-- 
Alan Curry

Message #11 received at 13912 <at> debbugs.gnu.org (full text, mbox):

From: Ellis N. Thomas <ExtraLeveLInSoftware <at> ntlworld.com>
To: Alan Curry <pacman-cu <at> kosh.dhis.org>
Cc: 13912 <at> debbugs.gnu.org
Subject: Re: bug#13912: Feedback on coreutils 8.13
Date: Wed, 13 Mar 2013 12:35:16 +0000

Alan,

	Many thanks for your rapid and sympathetic reply.

	One or two points about what you said embedded in parts of your reply
starting <<< below.

	As you have appreciated, I seem to have been caught in a "can't do
this until you have done that" sequence!  But I now seem ready to  
proceed
with building gcc.

	You finished by saying "The rest of the story needs to be read by  
someone
who actually knows MacOS." - does this mean someone else will contact  
me,
or do I need to forward any information?  See also below about  
config.log.

	Thanks,
		Ellis

By the way my background is that I have retired after working some  
years in the
development of software for embedded systems (defence and aerospace).
When I was in Cambridge University, England, studying Computer  
Science, my
supervisor was Stephen Bourne, who seems to be the same person that  
later
produced the Bourne Shell.  But my college course in 1969 was before  
Unix was
developed!

On 9 Mar 2013, at 22:38, Alan Curry wrote:

> ...
> Thanks for writing up your experience. Even though it's mostly a  
> series of
> bad choices, they were choices that only an outsider would make, so  
> they do
> reveal things that the insiders haven't thought of.
>
<<< Actually the only choice that mattered was to edit config.status!
<<< The attempts to use --enable- and --with- options seemed to be  
ignored.

> ...
> I found this surprising. I would have expected md5sum to be  
> installed with
> the OS. So I googled "md5sum macos" and the first result is a page  
> with
> installation instructions for a standalone package called  
> "md5sha1sum". That
> would probably be easier to install than coreutils, since it's much  
> smaller.
> I wonder how you managed to skip over it.
<<< What I found from a Google search was that Mac OS X has an md5  
command
<<< for similar use and man indicated this was a specific usage of  
openssl.
<<< However, it did not seem to provide the checking features of  
md5sum and
<<< worse its options did not match the man or info page (e.g. by  
trying md5 -h)!
<<< I probably just assumed that this was Apple's currently available  
feature here.
<<< It seemed easier to get md5sum than try to write a script to call  
md5 scanning
<<< the files listed in the file provided with gcc.

> and coreutils decided to make YET ANOTHER ONE (xz) mandatory.  
> "Compression
> format of the week" is a frustrating game! So I completely  
> understand your
> decision that...the only way to win is not to play. (If you did  
> choose to play, googling
> "macos xz" looks promising.)
>
<<< I had established that xz is available at http://tukaani.org/xz/,  
but did not feel
<<< inclined to start downloading from yet another site!  The Gnu site  
does not
<<< seem to mention handling xz files at all!
<<< By the way, Googling "macos xz" gave the response "Did you mean  
'mac os x'?"
<<< and only showed xz when overridden!

> ...
> You've understood that the documentation of "--without-PACKAGE" is  
> using the
> all-caps PACKAGE as a metasyntactic variable, which you're supposed to
> replace with the name of the package you want to do without. This  
> wasn't
> really explained but you figured it out anyway; congratulations on  
> getting
> that far.
<<< Actually at first (until I found an example) I thought it meant to  
use
<<< --enable-FEATURE=abc

>
> The other unexplained thing, which you didn't figure out, is that  
> the stuff
> below the generic --with-PACKAGE and --without-PACKAGE lines, from
> "--with-gnu-ld" to "--without-libintl-prefix", is the complete list  
> of valid
> PACKAGEs.
>
> ...
> md5sum isn't a feature you can enable/disable (--enable-FEATURE).  
> The help
> output lists them all.
> ...
> expr isn't a package you can with/without (--without-PACKAGE). The  
> help
> output lists them all.
>
> It's great that after all this trouble you've held on to your  
> optimistic
> belief that there must be some way of configuring just the program  
> you want,
> if only you can just find the right syntax. Sadly, it just isn't so.
<<< For coreutils (a suite of more or less unrelated commands) the  
actual
<<< meanings of FEATURE and PACKAGE did not seem to be well described.

>
> Ideally, "make src/md5sum" or "make -C src md5sum" would work, but the
> Makefiles in coreutils aren't quite good enough for it to work out  
> of the
> box. Some dependencies are missing.
<<< As I said before "it would help if it was possible to select  
specific parts of
<<< coreutils" easily.

> It sounds like configure found your not-yet-installed gmp and tried  
> to use
> it, with disastrous results. This is the part of the bug report  
> where you
> should include your config.log, so we can see exactly how that  
> HAVE_GMP
> became 1. And I won't be surprised if it turns out to be a bug  
> that's already
> fixed in 8.21.
<<< If it would help I can send the config.log, but it is 5.3MB - this  
takes us back
<<< into compression formats!  I seem to be able to do easily gzip,  
bzip2, and
<<< compress!

>> ...  So config.status was modified so that
>> D["HAVE_GMP"]=" 0"
>
> Editing a config.status by hand? That sure shows bravery and  
> determination.
<<< When I examined the expr.c source it was clear that conditional  
compilation
<<< catered for omitting gmp, and I searched all files timed stamped  
around the
<<< time I'd run configure to see where the flag was established.  It  
was only later
<<< that I found "--without-gmp" !

Message #14 received at 13912 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: "Ellis N. Thomas" <ExtraLeveLInSoftware <at> ntlworld.com>
Cc: 13912 <at> debbugs.gnu.org
Subject: Re: bug#13912: Feedback on coreutils 8.13
Date: Fri, 15 Mar 2013 22:24:23 -0600

Ellis N. Thomas wrote:
> 	As you have appreciated, I seem to have been caught in a "can't do
> this until you have done that" sequence!  But I now seem ready to
> proceed with building gcc.

Not to stop someone from working the problem and doing a good job of
it but it might be easier to simply install a GNU/Linux software
distribution on a system.  Then you would get everything all working
all at the same time.  It would probably be the easier way to go.  But
certainly if you are willing to work through the problems then I have
no doubt that you will have it working on your system.

> 	You finished by saying "The rest of the story needs to be read
> by someone who actually knows MacOS." - does this mean someone else
> will contact me, or do I need to forward any information?  See also
> below about config.log.

It was a comment that Alan had already spoken what he knew and didn't
know more about MacOS to say any more than that.  And I am in the same
position.  I don't use MacOS and so know nothing about it.  I can only
suggest that someone else who knows about MacOS would need to jump in
and help.  This is like tag team wrestling.  Except we have no idea if
there is someone else to jump in or not.

This is a free(dom) software project.  People voluteer time and
resources because we think it is worthwhile.  There is no paid
support.  Any help comes from people who volunteer the help out of the
goodness of their heart.  If someone is using MacOS and has
information then I am sure they will jump in and volunteer help.  But
there is no coordination on our end for it.

Most of us use the GNU system.  That is the whole point of it after
all.  We are "eating our own dogfood" as they say.  So I think it is
unlikely that we would have someone here who has bootstrapped
themselves using an Apple system.  Unlikely.  But who knows?

> By the way my background is that I have retired after working some
> years in the development of software for embedded systems (defence
> and aerospace).  When I was in Cambridge University, England,
> studying Computer Science, my supervisor was Stephen Bourne, who
> seems to be the same person that later produced the Bourne Shell.
> But my college course in 1969 was before Unix was developed!

Thank you for sharing that interesting history!  You were indeed lucky
to have been involved at the very beginning.  It has been an
interesting time for certain.

Although it might take some time to make the tools to make the tools
to make the tools I am sure that if you persevere that you will be
able to bootstrap yourself to a fully working system.  Please take
notes along the way and make those available to others who might want
to follow in your footsteps.

If in a future mailing you wish to simply discuss a topic then please
mail to the coreutils <at> gnu.org mailing list address.  That is our
discussion list.  The bug-coreutils <at> gnu.org address is used for bug
tracking.  As you can see from the email every message there creates a
bug ticket in the bug tracking system.  Which is great for tracking
individual bugs so that they do not get lost.  (Please submit one bug
per bug report.  No doubling up on bugs please.)  But for general
discussion please use the coreutils <at> gnu.org discussion list.

Bob

Message #19 received at 13912 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: "Ellis N. Thomas" <ExtraLeveLInSoftware <at> ntlworld.com>
Cc: 13912 <at> debbugs.gnu.org
Subject: Re: bug#13912: Feedback on coreutils 8.13
Date: Wed, 20 Mar 2013 14:46:17 -0600

Ellis N. Thomas wrote:
> 	As I said before: "The different effect for this Mac version might
> or might not be of relevance to Gnu developers!".

You would be surprised.  Most of us have spent a large portion of our
lives porting software from one platform to another! :-)

> 	If it would help, I am prepared to make separate bug reports for
> these matters.  On the other hand perhaps there is no point in following
> up problems in this old version of coreutils.  (What I wanted is working
> OK.)

Yes.  Please report each bug separately.  Because each reported bug is
tracked in the BTS (bug tracking system) and will be fixed
individually.  Mixing multiple bugs and topics in one bug report makes
it very difficult to follow.  Small individually targeted bugs are
easier to work through and more likely to be fixed than one big bag of
many things.

This message thread is a good travelogue of your journey but I don't
see a particular bug to be fixed.  Therefore I have marked this bug
ticket as closed.  Please feel free to continue adding information to
it.

If you want to *discuss* something without opening a bug ticket please
send discussion to the coreutils <at> gnu.org address.

If you find a bug please send them individually to the
bug-coreutils <at> gnu.org address where each message (like this one) will
open a bug ticket that is tracked.  If you have several bugs please
report them individually.  One bug per report please.  Feel free to
discuss them on the discussion list first.

Bob

Message #22 received at 13912 <at> debbugs.gnu.org (full text, mbox):

From: "Ellis N. Thomas" <ExtraLeveLInSoftware <at> ntlworld.com>
To: Bob Proulx <bob <at> proulx.com>
Cc: 13912 <at> debbugs.gnu.org
Subject: Re: bug#13912: Feedback on coreutils 8.13
Date: Wed, 20 Mar 2013 18:20:05 +0000

Bob,

	Thanks for your reply.  Actually I don't think details of MacOS itself
matter very much.  In this case I am using it at the Unix level, using  
xterm.
The Mac windows interface runs on top of the Darwin Unix kernel.  At  
xterm
level, much of the available set of commands seems to be Gnu derived
anyway, such as

bash --version
GNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0)

gcc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465)

	As included in my original message, the use of "make check"
reported an error, that might be new for this Darwin release,
"FAIL: install/install-C".

	In addition, failures that were already described in the README
from coreutils 8.13 for Darwin 9.1 were not reported for Darwin 9.8.0.

	As I said before: "The different effect for this Mac version might
or might not be of relevance to Gnu developers!".

	If it would help, I am prepared to make separate bug reports for
these matters.  On the other hand perhaps there is no point in following
up problems in this old version of coreutils.  (What I wanted is working
OK.)

	Thanks
		Ellis

On 16 Mar 2013, at 04:24, Bob Proulx wrote:

> It was a comment that Alan had already spoken what he knew and didn't
> know more about MacOS to say any more than that.  And I am in the same
> position.  I don't use MacOS and so know nothing about it.  I can only
> suggest that someone else who knows about MacOS would need to jump in
> and help.
...

> The bug-coreutils <at> gnu.org address is used for bug
> tracking.  As you can see from the email every message there creates a
> bug ticket in the bug tracking system.  Which is great for tracking
> individual bugs so that they do not get lost.  (Please submit one bug
> per bug report.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.