[bug #61302] Build errors

[G. Branden Robinson]

Update of bug #61302 (project groff):

                  Status:               Need Info => In Progress            

    _______________________________________________________

Follow-up Comment #3:

Hi, Deri!

[comment #2 comment #2:]

I'm trimming out the pnmutils and psselect stuff for now as those seem
exceptionally thorny, and/or to have arising from behavior changes across
versions.  Always a joy to deal with... :-/

> 
>     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.
> 
> 
> Very few of the rpms on my system include a *.pc file for pkg-config. For
example the lib64uchardet0 rpm contains these files:-
> 
> root@pip ~]#rpmq -l lib64uchardet0
> /usr/lib/.build-id
> /usr/lib/.build-id/3b
> /usr/lib/.build-id/3b/223b77034781d372e29bb70be3f320cdcf65ea
> /usr/lib64/libuchardet.so.0
> /usr/lib64/libuchardet.so.0.0.7
> 
> Even on a debian type system (osmc), admittedly this is a stripped back
version of debian, so may not have the dpkg hooks which may generate the .pc
file whilst installing, I don't know how it works. The ucharget.pc does not
exist anywhere, even though the library is installed:-
> 
> osmc@osmc3:~$ dpkg -L libuchardet0 
> /.
> /usr
> /usr/lib
> /usr/lib/arm-linux-gnueabihf
> /usr/lib/arm-linux-gnueabihf/libuchardet.so.0.0.6
> /usr/share
> /usr/share/doc
> /usr/share/doc/libuchardet0
> /usr/share/doc/libuchardet0/changelog.Debian.gz
> /usr/share/doc/libuchardet0/copyright
> /usr/lib/arm-linux-gnueabihf/libuchardet.so.0

I'd expect pkg-config-related .pc files to be in packages called `-dev`
(Debian) or `-devel` (Red Hat), because they're only useful on platforms where
development happens.


$ dpkg -L libuchardet-dev | grep -F .pc
/usr/lib/x86_64-linux-gnu/pkgconfig/uchardet.pc


> 
>      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. 
> 
> 
> This is a strange one!!
> 
> If you change the first line to #!/bin/bash (which is my default shell), the
test fails. The reason is because under bash the two back slashes (\\n[PN])
are not consumed by the shell, so groff is emitting "This is page \n[PN]."
which is not what you want. Under dash one of the back slashes is consumed
before being passed to groff, so you get a test pass.
> 
> 
>      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)? 
> 
> 
> Another dash/bash difference, change to bash and test fails, remove the grep
and the reason is obvious - different output from groff.

Yup.  I got sloppy and used `echo` with embedded quoted backslashes, which is
unfortunately not portable.  I've just changed the tests to use `printf` and
checked those tests with both dash and bash and they work now.

I'll push fixes for these tests momentarily.

> Well I think I've diagnosed all the reasons why the build and checks have
problems on non-debian flavours. I'm not sure if these dashisms are portable
to non-linux systems.

Fortunately I don't think we're dealing with dashisms here, but rather the
old, old problem of `echo` being unreliable.

> I'll pursue the psselect issue a little more. I will try to find out whether
it is all groff documents with eps files embedded which confuse psselect, or
whether it is something particular about the workflow which produces gnu.eps.
One question, I can't find any versions on my system, on old disks which
included webpage.html, is this relatively new?

It shipped in the "groff" (but not groff-base) package in Debian's groff
1.22.4 packages, and I think it goes back much farther than that (before my
time).  Lines 107-114 in doc/doc.am date back to a Bertrand commit (migrating
groff to Automake) in September 2014.

What distributors ultimately decide to ship is another question.  :-/

I'm marking this ticket as "In Progress" since we're both working on things,
though you've grabbed the more difficult tasks.

    _______________________________________________________

Reply to this item at:

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

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