[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:
[35mwarning:[39;49m POSIX Yacc does not support %expect
[[35m]8;id=b5627ee30005cdb64161b23e00000000;https://www.gnu.org/software/bison/manual/html_node/Diagnostics.html#Wyacc\-Wyacc[39;49m]8;;\]
63 | [35m%expect[39;49m 2
| [35m^~~~~~~[39;49m
/home/derij/groff-git/groff/build/../src/preproc/pic/pic.ypp:1391.11-1396.17:
[35mwarning:[39;49m rule useless in parser due to conflicts
[[35m]8;id=b5627ee30005cdb64161b23e00000001;https://www.gnu.org/software/bison/manual/html_node/Diagnostics.html#Wother\-Wother[39;49m]8;;\]
1391 | | [35mORDINAL LAST object_type relative_path[39;49m
| [35m^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[39;49m
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/
- [bug #61302] Build errors, Deri James, 2021/10/06
- [bug #61302] Build errors,
G. Branden Robinson <=
- [bug #61302] Build errors, Deri James, 2021/10/08
- [bug #61302] Build errors, G. Branden Robinson, 2021/10/09
- [bug #61302] Build errors, G. Branden Robinson, 2021/10/09
- [bug #61302] Build errors, Deri James, 2021/10/09
- [bug #61302] Build errors, Deri James, 2021/10/09
- [bug #61302] Build errors, Deri James, 2021/10/09
- [bug #61302] [tests] non-portable use of echo, G. Branden Robinson, 2021/10/28