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 <[EMAIL PROTECTED]>: > > > > > >> 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/groff@gnu.org/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
