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.
