回复: [Groff] building process stuck wh en building groff-current using MinGW

[Yu-ning Feng]

I should deal with my MinGW and msys. Maybe a reinstall.
Truly thanks for the confirm build and other information.

2007/9/7, Keith MARSHALL <address@hidden>:
>
>
>
>
> >> 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.
>


-- 
Yu-ning Feng