Yu-ning Feng wrote:
> On 9/11/07, Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>
>> Aah, there is indeed an issue. Running
>>
>> valgrind tbl < mixed_pickles.roff > /dev/null
>>
>> reveals indeed both an invalid write and read.
Strange, that this never bit me. Still, such faults do tend to a
On 9/11/07, Yu-ning Feng <[EMAIL PROTECTED]> wrote:
> On 9/7/07, Keith MARSHALL <[EMAIL PROTECTED]> wrote:
> >
> > 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 th
> On Monday 10 September 2007 08:37, Werner LEMBERG wrote:
>>> I have tried netpbm 10.18.4 (with libpng 1.2.7). It works. The
>>> problematic one is netpbm 10.27 (with libpng 1.2.8). All from
>>> GnuWin32.
>>
>> Ah! So at least this problem is not related to groff. Please report
>> this probl
Yu-ning Feng wrote, quoting me:
>> Let me guess; you're using MSYS, and you ignored the advice to steer
>> clear of rxvt? I think I need to assert that more authoritatively, in
>> the README.MinGW file, (which I hope you've read).
>
> It would be better to mention the caveat in "BUILDING" sect
> With CDB (a user mode dbgr on win) and symbol file of ntdll.dll, I
> have got a more exact crash point: [...]
The GDB backtrace was already sufficient to identify the problem.
Werner
> Finally there, may be / may not be the real problem. Description of
> the crash: [...]
Aah, there is indeed an issue. Running
valgrind tbl < mixed_pickles.roff > /dev/null
reveals indeed both an invalid write and read. This is fixed now in
the CVS. Please test!
Werner
On 9/11/07, Yu-ning Feng <[EMAIL PROTECTED]> wrote:
> On 9/7/07, Keith MARSHALL <[EMAIL PROTECTED]> wrote:
> >
> > 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 th
On 9/7/07, Keith MARSHALL <[EMAIL PROTECTED]> wrote:
>
> 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.
Would like to know the v
On Monday 10 September 2007 08:37, Werner LEMBERG wrote:
> > I have tried netpbm 10.18.4 (with libpng 1.2.7). It works. The
> > problematic one is netpbm 10.27 (with libpng 1.2.8). All from
> > GnuWin32.
>
> Ah! So at least this problem is not related to groff. Please report
> this problem to the
> I have done a fast tracing:
>
> (gdb) start
> Breakpoint 2 at 0x406d7a: file main.cpp, line 1525.
> Starting program: f:\tools\groff-current/src/preproc/tbl/tbl.exe
> contrib/hdtbl/e
> xamples/mixed_pickles.roff
> main (argc=2, argv=0x3d2498) at main.cpp:1525
> 1525{
Ah, yes, here I can s
> > Please compile groff like this:
> >
> > ./configure CFLAGS="-g -O0" CXXFLAGS="-g -O0" LDFLAGS="-g"
> > make
> >
> > and redo the backtrace.
>
> I have followed the instructions above, but see no difference.
This is impossible! The above configure command explicitly adds
debugging info to
> A problem with many make files is they do
>
> cmd data >foo
>
> instead of
>
> cmd data >foo.tmp && mv foo.tmp foo
>
> or similar.
In this particular case such additional protection is unnecessary
since Joe User isn't expected to compile from the CVS. However, I
don't mind if a goo
Hi,
Keith Marshall wrote:
> In fact, it generates a zero length gnu.png, which is sufficient to
> let the build continue on a second make pass;
A problem with many make files is they do
cmd data >foo
instead of
cmd data >foo.tmp && mv foo.tmp foo
or similar. Imagine if cc(1) worked
> I have tried netpbm 10.18.4 (with libpng 1.2.7). It works. The
> problematic one is netpbm 10.27 (with libpng 1.2.8). All from
> GnuWin32.
Ah! So at least this problem is not related to groff. Please report
this problem to the netpbm people (or maybe a newer version has
already been released
> Here is the gdb backtrace.
Thanks. It's completely useless, of course, because I've forgotten to
tell you to compile groff with debugging informations.
> Do I need to change something to generate it?
Please compile groff like this:
./configure CFLAGS="-g -O0" CXXFLAGS="-g -O0" LDFLAGS="-g
2007/9/10, Yu-ning Feng <[EMAIL PROTECTED]>:
> > Say
> >
> > gdb --args tbl mixed_pickles.roff
> >
> > then press `r' (and ignore tbl's output to stdout). If tbl crashes,
> > press `bt full' and cut'n'paste the backtrace.
> >
>
> I will do this later.
>
> >
> > Werner
> >
>
Here is the gdb
2007/9/10, Werner LEMBERG <[EMAIL PROTECTED]>:
> > > Indeed. It stops with a very mysterious error not related to
> > > groff at all. Is it possible that your netpbm package is broken,
> > > containing a bad `pnmtopng' executable? Can you call this program
> > > successfully at all?
> >
> > In m
> > Indeed. It stops with a very mysterious error not related to
> > groff at all. Is it possible that your netpbm package is broken,
> > containing a bad `pnmtopng' executable? Can you call this program
> > successfully at all?
>
> In msys, if I run it with some option, say --version, it gives
On Sun, 2007-09-09 at 20:39 +0200, Werner LEMBERG wrote:
> > I removed the groff-current source directory, extracted the package,
> > and maked again. I discovered something interesting. At first make,
> > make stopped much earlier.
>
> Indeed. It stops with a very mysterious error not related to
> I removed the groff-current source directory, extracted the package,
> and maked again. I discovered something interesting. At first make,
> make stopped much earlier.
Indeed. It stops with a very mysterious error not related to groff at
all. Is it possible that your netpbm package is broken,
On Sat, 2007-09-08 at 23:11 +0800, Yu-ning Feng wrote:
> CRLF is the reason. I forgot to mention I was using CVS code that
> time. I did not know that CVS client would do LF -> CRLF then
> (downloaded from
> http://ftp.gnu.org/non-gnu/cvs/binary/stable/x86-woe/cvs-1-11-22.zip).
> I checked my syste
2007/9/7, Keith MARSHALL <[EMAIL PROTECTED]>:
> However, your problem is quite specific, and I happen to have spent some
> time analysing the particular circumstances which cause it. It is caused,
> very specifically, by a command substitution of the form:
>
> $ some command "anything`command pr
> > 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 :-)
Thanks in advance :-)
> However, `make install' failed rig
Webb Roberts wrote, quoting me:
>> $ some command "anything`command producing CRLF output`anything" ...
>> [on MSYS: introduces stray \01 byte after `command ...`]
>
> You might escape this problem through use of the $(shell command)
> function, instead of `command`. Just a thought.
Nope. Th
Keith MARSHALL wrote:
$ some command "anything`command producing CRLF output`anything" ...
You might escape this problem through use of the $(shell command) function,
instead of `command`. Just a thought.
Webb
--
Webb Roberts
Georgia Tech Research Institute
> > > 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`
>
> This is li
>> 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.
2007/9/7, Yu-ning Feng <[EMAIL PROTECTED]>:
> 2007/9/7, Werner LEMBERG <[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' progr
> 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. As a temporary
I modified msys.bat and used sh.exe to start msys.
I still got problem while making. Please see the bottom.
By some way I let make go on and finished.
When make install, some error occur,
mkdir -p -- D:/groff-cvs/share/groff/1.19.3
mkdir: cannot create directory `D:/groff-cvs/share/groff/1.19\00
2007/9/6, Keith MARSHALL <[EMAIL PROTECTED]>:
>
>
> Let me guess; you're using MSYS, and you ignored the advice to steer
> clear of rxvt? I think I need to assert that more authoritatively, in
> the README.MinGW file, (which I hope you've read).
>
It would be better to mention the caveat in "BUIL
2007/9/6, Keith MARSHALL <[EMAIL PROTECTED]>:
>
> Let me guess; you're using MSYS, and you ignored the advice to steer
> clear of rxvt? I think I need to assert that more authoritatively, in
> the README.MinGW file, (which I hope you've read).
You are right. I was using MSYS with rxvt. I had read
Yu-ning Feng wrote:
> I downloaded groff-current from http://groff.ffii.org/groff/devel/
> and tried to build it in MinGW.
>
> binutils 2.17.50
> gcc, g++ 3.4.5
> mingw-runtime 3.13
> w32api 3.10
> msys 1.0.10
>
> when making, it stuck. The last message printed was as below:
>
> GROFF_COMMAND_P
I downloaded groff-current from http://groff.ffii.org/groff/devel/ and
tried to build it in MinGW.
binutils 2.17.50
gcc, g++ 3.4.5
mingw-runtime 3.13
w32api 3.10
msys 1.0.10
when making, it stuck. The last message printed was as below:
GROFF_COMMAND_PREFIX=''; export GROFF_COMMAND_PREFIX;
GROFF_
34 matches
Mail list logo
