Re: [Gnu-arch-users] Make test failure on Cygwin

[Ron Parker]

On Tue, 06 Jul 2004 15:46:30 -0500, John Meinel <address@hidden> wrote:
> Well, one thing Leroy mention is to use the flag ./configure
> --with-posix-shell=/usr/bin/bash sort of thing. I'm all for that :).

That may work, I will have to try it.

> I'm very curious why the "sed" output is different from the
> "unit-unidata" version. I know I have cygwin designed to use Unix line
> endings internally. At least I believe so. (That's caused problems
> trying to use cmd line cvs versus a Win32 gui cvs.)

The short answer is that sed forcibly opens its output in Windows
text-mode effectively reducing all \r\n sequences to \n no matter what
mount mode is used.

Now this may or may not be true for piped input, but my experience
would seem to indicate that Cygwin's bash also opens pipes in text
mode.  I have not tried the "nobinmode" setting, as I prefer \n line
endings and really don't wan't all \r\n sequences that might be in a
binary file altered just because I pipe them through some filters. 
(No, I don't do this often, but I have been known to need to tweak a
binary on occasion.)

> > It's not just your system.  Long long ago in a galaxy far far away, it
> > was decided that the Cygwin text tools should always operate in text
> > mode, irrespective of mount mode or anything else and this becomes
> > even more obfuscated when dealing with pipes. At least a partial
> > description may be found in the thread at
> > http://www.cygwin.com/ml/cygwin/2002-08/msg01597.html. My experience
> > doesn't seem to completely match this description but I may be having
> > a memory fault.
> 
> Maybe I just didn't read enough, but what I saw was that a redirect '>'
> works in bin or text depending on mount mode and a pipe works depending
> on the CYGWIN=[no]binmode. I can look into it a little bit more. If that
> fixes it, we might be okay. However, as mentioned, my guess is that sed
> is doing binmode, but unit-unidata is using native mode.

You  read it correctly. Remembering that sed always reduces \r\n on
input, if your output is redirected to a text-mode mount, then all \n
seen by sed will be converted to \r\n. Since the file has been mangled
on input, it does this whether or not a \r\n was used originally.
OTOH, if your output goes to a binary-mode mount, then all \n seen by
sed will be written out as \n and a \r\n will never be produced.

> >>If I add dos2unix ,tmp2, then the comparison works. I'm not sure if
> >>there is a better way that involves changing unit-unidata.c, or
> >>something like that.

There is no perfect answer here, I would bet that currently the test
fails if building on a binary mode mount and if unit-unidata.c was
changed to use \n, then the test would fail on text mode mounts.

> Well, one thing that you could do is run "dos2unix" on both ,tmp and
> ,tmp2, then you are at least working with the same data. You could run
> unix2dos, I don't really care. But having the test fail because of line
> endings doesn't seem right. Unless there is something specific about the
> processing chain that requires line endings to be correct, so that a
> failing the test really is a failure.

True but dos2unix is a Cygwinism and I was targeting something that
would work regardless of OS. Two reasons here.  I use more operating
systems than anyone should and I was hoping at some point in time to
be able to at least have some of this merged back into the baseline.


> I don't know if this would be the problem, but what if tla is using the
> wrong versions of tar/diff/patch etc?

I don't think it would be using the wrong version because an explicit
../libexec path should be getting used to exec them.  However, as I
previously mentioned I have not checked to see if it might be using a
stale version that already exists from a previous install.

> Just the auto* errors. One thing I would say is probably we want to
> distribute the "generic" Makefile.in. I was reading some of the help
> files and unless you do "make distsomething" the Makefile.in may not be
> a portable one. I would like to see the situation where ./configure runs
> configure for all the packages, and then make only does the build.
> Having make also run ./configure for the tar/patch/diffutils stuff
> doesn't seem quite right.

Take it up with the author of package framework. :^) Seriously, its
been a few months since I dug into this and I _vaguely_ recall that
Makefile.in must exist when configure is run weather or not the
project is autotool based.

Okay, I just rechecked this. Package framework calls the configure
script for the autotools managed projects directly. It also relies on
the functionality in the newer autotools that will essentially
autoreconf everything if the generated files are out of date. (This
happens when make is called.) Simply calling configure keeps the
package framework from necessarily requiring an installation of a
certain version of the autotools.