Re: [Groff] building process stuck when building groff-current using MinGW

[Keith MARSHALL]

>> mkdir -p -- D:/groff-cvs/share/groff/1.19
.3
>> mkdir: cannot create directory `D:/groff-cvs/share/groff/1.19\001.3':
>> No such file or directory
>
> This looks like a broken `cat' program on msys which doesn't handle
>
>   version=`cat $(top_srcdir)/VERSION`
>
> in the Makefile correctly.

No, this isn't the problem.  The problem is a consequence of shell
substitution introducing a stray byte, (always \01), as described in
the autoconf documentation, (search for MSYS, within this page):
http://www.gnu.org/software/automake/manual/autoconf/Shell-Substitutions.html

FTR, the OP should *not* be seeing this problem, if he has installed
MSYS correctly.  Notice that the bug is triggered by *native* programs
only, (i.e. programs which produce CRLF delimited text mode output).
MSYS ships with versions of cat and sed which produce only LF delimited
text mode output, and do not trigger this bug.  For the OP to be seeing
this, he *must* have alternative cat and/or sed programs preceding the
MSYS versions in his PATH -- he should rectify that anomaly.

The bug is present in the bash-2.04 shipped with MSYS up to 1.0.10;
it is not present in the bash-3.1 which will ship with MSYS-1.0.11,
and which may be found here, (should also work in MSYS-1.0.10):
http://downloads.sourceforge.net/mingw/bash-3.1-MSYS-1.0.11-snapshot.tar.bz2

> As a temporary workaround (so that you build succeeds), replace
> this with
>
>   version=1.19

Better yet, would be for us to apply the autoconf workaround, within
the sources; I guess I've just walked into a job here :-)

>> when roffing mixed_pickles.roff, a window pop out,
>>
>>  tbl.exe meet a problem and need to be terminated
>>  debug, send error report...
>
> Hmm.  I'm clueless here.

That usually means a segmentation fault; FWIW, I cannot reproduce it.

>> when processing pdfmark.pdf,
>>
>>  GPL Ghostscript 8.15: Unrecoverable error, exit code 1
>>
>> I noticed that someone met the same problem before
>> (http://www.mail-archive.com/address@hidden/msg01688.html).

And it went away, when he did a `make clean', to remove the detritus
of a previously failed build, before running `make' again'.

>> I tried GS 8.15 and 8.60. Same result.
>
> Hopefully, someone can help you.  It might be useful to test the SVN
> repository of GS too.

I don't think that will help.  It was Larry Kollar who reported the
previous failure.  If I could reproduce it, I would investigate further,
but it stubbornly continues to DTRT for me, both on GNU/Linux and Woe32.

It has been some time since I last built groff on Woe32, but I've just
been through the exercise again this morning, using the current snapshot
from: http://groff.ffii.org/groff/devel/groff-current.tar.gz

After I'd sorted out such things as missing or broken bison and netpbm
tools, (this is on a relatively new Woe2K box), it built successfully,
from `make clean' state all the the way to fully built, without error.
However, `make install' failed right at the bitter end, because this:

   cd $(DESTDIR)$(dataprogramdir); \
   rm -f current; \
   $(LN_S) $(version)$(revision) current

can never work on a native Woe32 system.  (In fact, it can only *ever*
work if $(LN_S) resolves to `ln -s', or maybe to `ln'; there are systems,
of which Woe32 with MSYS is one, where $(LN_S) resolves to `cp -p', and
on such systems, this *must* *always* fail).

Regards,
Keith.