Update of bug #68370 (group groff):

                Category:                    None => General
              Item Group:                    None => Build/Installation
                  Status:                    None => Need Info

    _______________________________________________________

Follow-up Comment #1:

Hi Ross,

I have a couple of questions for you below.

[comment #0 original submission:]
> Heavily parallel builds fail with missing build dependencies, for example:
> 
> groff-1.24.1/groff: error: couldn't exec pic: No such file or directory
> pdfmom: fatal error: test-groff exited with status 24
> make[2]: *** [Makefile:19272: doc/automake.pdf] Error 1
> 
> Adding 'pic' to the 'doc/automake.pdf' target in doc/doc.am seemed to solve
> that, but I suspect there's a better location to put the dependency.

Thanks for the report.  I think the nature of the problem differs slightly;
"doc/automake.pdf" _shouldn't_ need a _pic_ dependency because it doesn't use
_pic_(1).  And I don't see such a dependency declared in 1.24.1's
"doc/doc.am".

https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/doc/doc.am?h=1.24.1#n88
https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/doc/doc.am?h=1.24.1#n140

However, we may have gotten careless by having "pdfmom" declare a dependency
on _pic_...except I don't see one in its Automake file, either.

https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/src/devices/gropdf/gropdf.am?h=1.24.1#n51

So I'm puzzled as to why _groff_(1) is trying to run _pic_(1).

I can't see anything in "pdfmom.pl" itself forcing the "-p" option to be
passed to _groff_.

https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/src/devices/gropdf/pdfmom.pl?h=1.24.1

Incidentally, that "exit status 24" tells us some things.

_groff_(1):

Exit status
     groff exits successfully (with status 0) if either of the options
     -h or --help is specified, status 2 if the program cannot interpret
     its command‐line arguments, and status 1 if it encounters an error
     during operation.  Otherwise, groff runs a pipeline to process its
     input; if all commands within the pipeline exit successfully, groff
     does likewise.  If not, groff’s exit status encodes a summary of
     problems encountered, setting bit 2 if a command exited with a
     failure status, bit 3 if a command was terminated with a signal,
     and bit 4 if a command could not be executed.  (Thus, if all three
     misfortunes befall one’s pipeline, groff exits with status 2^2 +
     2^3 + 2^4 = 4+8+16 = 28.)  To troubleshoot pipeline problems, re‐
     run the groff command with the -V option and break the reported
     pipeline down into separate stages, inspecting the exit status of,
     and diagnostic messages emitted by, each command.


So, 24 = 8+16 = 2^3 + 2^4 => "a command could not be executed"
                          => "a command was terminated with a signal"

...which would indeed be consistent with pipeline failure due to a command
within the pipeline being absent.

Can you reproduce this problem by re-rerunning make and passing "V=1" to
_make_(1) so that we can see the exact command that is being used on your
system to build the "doc/automake.pdf" target?

Is this build from a stock groff-1.24.1.tar.gz archive?

https://ftpmirror.gnu.org/gnu/groff/


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?68370>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature

Reply via email to