Re: `print' does not print

[Eli Zaretskii]

> Date: Fri, 22 Mar 2002 23:18:44 +0100
> From: Ralf Fassel <ralf@akutech.de>
> 
> So there _is_ a difference: cc fills the struct, gcc doesn't.

Yes.  The important part in the difference is that with cc, a new
buffer is allocated to hold the buffered characters, while in the gcc
build, _base stays at 0x0, i.e. the buffer wasn't allocated.  (It is
normal for buffered I/O routines to start with the buffer of teh FILE
object unallocated, and only allocate it the first time any operation
is requested for that FILE object.)

> gcc:
> 
>     fwrite () at engine.c:601
>     _wrtchk () at exportent.c:396
> !   setoserror () at aio.c:314
>     _wrtchk () at exportent.c:383
>     383       exportent.c: No such file or directory.
>     fwrite () at engine.c:554
>     printchar (ch=34, fun=273132596) at print.c:334

setoserror means there's some kind of error where it should have
allocated the buffer (that's the _findbuf call in the cc build, I
guess).  Can you zero out errno before the call to fwrite, and see if
it gets any value after fwrite returns?

>     Program received signal SIGTRAP, Trace/breakpoint trap.
> 
> and I always get that SIGTRAP which restarts the fwrite again, but the
> difference at ! is obvious.

Probably a bug in GDB (SIGTRAP means that a breakpoint fired, but GDB
didn't think there was a breakpoint at that place in the program).

Anyway, this is a point where I'd strongly suggest compiling the
library routines with enough debug info to be able to step through
the library code and see what's wrong with Emacs.  I guess in your
case it's hard, since the library is proprietary, but the other
report about the same behavior was for GNU/Linux, where we have
glibc.  Can someone please step through the glibc code in this case
and see what's going on?