minor syntax issues when building Guile on older setups

[Gordon Steemson <gsteemso@gmail.com>]

I'm trying to compile a more recent Guile than 2.0.11 (the version available through my package manager) on my old Power Mac G5, and have thus far encountered two minor issues when building 3.0.10:

Firstly:  In libguile/print.h and libguile/dynstack.h, the header libguile/scm.h is included right before a typedef that elaborates upon a typedef in scm.h.  Specifically, libguile/scm.h says

> typedef struct scm_print_state scm_print_state;
> typedef struct scm_dynstack scm_t_dynstack;

then libguile/print.h says

> typedef struct scm_print_state {
>   [ 14 lines of structure members & comments ]
> } scm_print_state;

and libguile/dynstack.h says

> typedef struct scm_dynstack {
>   [ 3 lines of structure members ]
> } scm_t_dynstack;

Older GCCs are confused by this framing and mistake it for a redefinition of the type alias, which is a fatal error.  The fix is to merely define the structures, rather than making a second typedef statement out of them -- you don't need to reiterate that they're typedefs, that each is a typedef is already stated in scm.h immediately prior.  Like this...

In libguile/print.h:

> struct scm_print_state {
>   [ 14 lines of structure members & comments ]
> };

and in libguile/dynstack.h:

> struct scm_dynstack {
>   [ 3 lines of structure members ]
> };

(I'll also add here that the literal form feeds embedded in these source files make it unnecessarily fiddly to construct patches for them.  Seriously, that stopped being an unambiguously good idea 40 years ago.)

Secondly:  In libguile/posix.c, there is exactly one use of “dprintf()”.  This function does not exist on my machine, which ceased to be supported by its manufacturer before dprintf() was standardized.  I request that either a more portable alternative, or the gnulib module which makes dprintf() reliably available, be used.  (Using “fprintf()” instead seems to work here, but this occurs in an error handler and for all I know there may have been a very good reason the existing code writes specifically to a file descriptor rather than to a stream, so I'm not about to declare it an obvious change to make.)

I do not have any other issues to report on a purely mechanical "proofreading" level, but I can't really comment on whether Guile actually operates as intended because it is still bootstrapping itself after 11 continuous hours.  (Based on the list of source files in stage0/Makefile.in, I am reasonably confident it will proceed to stage one from stage zero some time in the next two or three hours.)  Is it normal for it to take this long?  I know two cores at 2 GHz is a bit slow by today's standards, but even GCC 7 builds to completion on this thing in only about 18 hours.

Gordon S.