minor syntax issues when building Guile on older setups

[Gordon Steemson]

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.