Re: mktime() problem when building print/a2ps

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 14 Oct 2022 07:28:45 -0700 (PDT)
    From:        Paul Goyette <paul%whooppee.com@localhost>
    Message-ID:  <Pine.NEB.4.64.2210140723300.12345%speedy.whooppee.com@localhost>

  | kre@ noticed some comments in the code regarding mktime().

Yes, but given the actual problem, that (and everything related to
the actual mktime() tests) is irrelevant.

  | i also
  | noticed that a2ps built correctly when building it as a dependency
  | for something else (magicfilter).

My guess on that one is that probably some earlier dependency of
magicfilter also tested for mktime(), did it properly, and the result
was then cached, so a2ps's configure script didn't need to run the
test program.

  | Yet when i rebuilt it again "by itself" it hung again.  interestingly,
  | a Ctrl-C/bg/fg seqence gave it a kick and it continued normally after
  | that.

I suspect we currently have a signal handling (particularly regarding SIGCONT)
bug in the kernel syscall handling (PR kern/57052 is probably another example
of it, though leading to different results).

  | Looking at the code, it seems that the alarm(60) didn't work.

This one is the interesting issue in all of this - why that is happening to
some people, and not others.   Perhaps there's a preemption problem,
with an arriving signal not forcing the process into the kernel, but
leaving it running in user mode - then the results would differ depending
upon whether some other factor caused the process to be preempted (cpu required
for a higher prior process perhaps).   I am just guessing...

kre