bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #61302] Build errors


From: G. Branden Robinson
Subject: [bug #61302] Build errors
Date: Thu, 7 Oct 2021 01:17:47 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Update of bug #61302 (project groff):

                  Status:                    None => Need Info              
             Assigned to:                    None => gbranden               

    _______________________________________________________

Follow-up Comment #1:

Hi Deri,


BuildFoundries: notice: Generated U-PR...
afmtodit: both Upsilon and Upsilon1 map to *U at
/home/derij/groff-git/groff/build/afmtodit line 6441.
BuildFoundries: notice: Generated U-S...


This has "always" been there, but about a year ago I made the complaining
program identify itself (3b680c85).  It's ignorable, though I'd like to do
something about it.  I guess we should pick one of these Adobe glyphs for our
*U character--whichever one is more useful for scientific/mathematical use of
Greek, I reckon, and tell users they'll need to get the other via the \N
escape sequence.


  YACC     src/preproc/pic/pic.cpp
/home/derij/groff-git/groff/build/../src/preproc/pic/pic.ypp:63.1-7:
warning: POSIX Yacc does not support %expect
[]8;id=b5627ee30005cdb64161b23e00000000;https://www.gnu.org/software/bison/manual/html_node/Diagnostics.html#Wyacc\-Wyacc]8;;\]
   63 | %expect 2
      | ^~~~~~~
/home/derij/groff-git/groff/build/../src/preproc/pic/pic.ypp:1391.11-1396.17:
warning: rule useless in parser due to conflicts
[]8;id=b5627ee30005cdb64161b23e00000001;https://www.gnu.org/software/bison/manual/html_node/Diagnostics.html#Wother\-Wother]8;;\]
 1391 |         | ORDINAL LAST object_type relative_path
      |           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


I see these all the time.  They're "harmless", like the afmtodit warning, but
I'd like to fix them some day.


  GROFF    doc/pic.html
[2] [1] Wrote 1 pages
pnmcrop: The image is entirely background; there is nothing to crop.


This is bad news.  I don't get these.  Something is going wrong in/around
grohtml.  I expect your copy of the HTML version of the pic manual is missing
all of its images and is therefore nearly useless.  That's a showstopper.  I
broke but then fixed grohtml over the course of a couple of days, though I
don't remember seeing these exact diagnostics.  If you're on a branch
(sboxes?) make sure you have commit 991aa9da (30 July).  But don't get your
hopes up--I suspect you do have it because you're seeing errors from the pnm*
suite, and another change of mine around the same time made these changes
visible (98367a84, 26 July).


  GROFF    doc/automake.pdf
troff: ../doc/automake.mom:56: error: can't transparently output node at top
level


These have been a fixture of mom(7) for a long time; we're resigned to telling
people to ignore them.


  GROFF    doc/webpage.html
[1] [1] Wrote 1 pages
pnmcut: Error reading first byte of what is expected to be a Netpbm magic
number.  Most often, this means your input file is empty
pnmcrop: Error reading first byte of what is expected to be a Netpbm magic
number.  Most often, this means your input file is empty
pnmtopng: Error reading first byte of what is expected to be a Netpbm magic
number.  Most often, this means your input file is empty
Calling 'pnmcut 100 119 702 182 < /tmp/groff-page-2lqna3 | pnmcrop -quiet |
pnmtopng -quiet -background rgb:f/f/f -transparent rgb:f/f/f>
img/webpage-1.png
' returned status 256
[2] [1] Wrote 1 pages
GPL Ghostscript 9.53.3: Unrecoverable error, exit code 1
Calling 'echo showpage | gs -q -dBATCH -dSAFER -dDEVICEHEIGHTPOINTS=792
-dDEVICEWIDTHPOINTS=700 -dFIXEDMEDIA=true -sDEVICE=pnmraw -r100
-dTextAlphaBits=4 -dGraphicsAlphaBits=4  -sOutputFile=/tmp/groff-page-2lqna3
/tmp/groff-ps-3FDKs6 -
' returned status 256
sh: line 1: /tmp/groff-page-2lqna3: No such file or directory
pnmcrop: Error reading first byte of what is expected to be a Netpbm magic
number.  Most often, this means your input file is empty
pnmtopng: Error reading first byte of what is expected to be a Netpbm magic
number.  Most often, this means your input file is empty
Calling 'pnmcut 103 322 137 224 < /tmp/groff-page-2lqna3 | pnmcrop -quiet |
pnmtopng -quiet -background rgb:f/f/f -transparent rgb:f/f/f>
img/webpage-2.png
' returned status 256


This looks bad and I'm guessing it has a similar cause as the pic.html
trouble.  Your version of gs (9.53.3) is newer than mine
(9.27).


mkdir -p ./contrib/sboxes/
./test-groff -M../contrib/sboxes -ms -msboxes -Tpdf
../contrib/sboxes/msboxes.ms > contrib/sboxes/msboxes.pdf


This reminds me that I still owe you some work in this area.


configure:21717: checking pkg-config is at least version 0.9.0
configure:21720: result: yes
configure:21739: checking for UCHARDET
configure:21746: $PKG_CONFIG --exists --print-errors "uchardet >= 0.0.1"
Package uchardet was not found in the pkg-config search path.
Perhaps you should add the directory containing `uchardet.pc'
to the PKG_CONFIG_PATH environment variable
Package 'uchardet', required by 'virtual:world', not found
configure:21749: $? = 1
configure:21763: $PKG_CONFIG --exists --print-errors "uchardet >= 0.0.1"
Package uchardet was not found in the pkg-config search path.
Perhaps you should add the directory containing `uchardet.pc'
to the PKG_CONFIG_PATH environment variable
Package 'uchardet', required by 'virtual:world', not found
configure:21766: $? = 1
configure:21780: result: no
Package 'uchardet', required by 'virtual:world', not found
configure:21802: WARNING: uchardet library not found, preconv might not work
properly


This is the uchardet issue you noted.  Is it common for libuchardet to be
installed without its pkg-config support in place?  A more traditional
Autoconf test might be useful, I admit.

I didn't see anything else that jumped out at me in config.log, but the file
is huge.  Please call out anything I missed.

Moving on to the test suite log...


FAIL: tmac/tests/s_PN-works.sh
==============================

FAIL tmac/tests/s_PN-works.sh (exit status: 1)


Can you have a look at the body of the test and try to reproduce it with
test-groff in your build?  It's really simple and I can't imagine what might
have gone wrong.  This test does not fail on HEAD.


FAIL: src/roff/groff/tests/break_zero-length_output_line_sanely.sh
==================================================================

troff: <standard input>:10: warning [p 0, 0.0i, div 'A', 0.0i]: can't break
line
troff: <standard input>:11: warning [p 1, 0.0i]: can't break line
FAIL src/roff/groff/tests/break_zero-length_output_line_sanely.sh (exit
status: 1)


This one bears close examination too.  Are you on a branch?  Did you somehow
not get commit 69efbe0a (4 September)?

The bad news(?) is that HEAD is green for me, so I'll need your help to chase
these down.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]