Re: [platform-testers] groff 1.23.0.rc3 on Solaris 10

[G. Branden Robinson]

Hi Bruno,

At 2023-03-06T01:40:37+0100, Bruno Haible wrote:
> On Solaris 10, I tried two compilers:
> 
> * The Sun C, C++ compilers.
> 
>   This resulted in a build failure:
> 
> CC -xarch=generic64 -O -DHAVE_CONFIG_H -I. -I.. -I./src/include  
> -I../src/include -I../lib -I./src/include -I./lib 
> -I/home/haible/prefix-x86_64/include  -g -c -o src/devices/grodvi/dvi.o 
> ../src/devices/grodvi/dvi.cpp
> "/usr/include/stdbool.h", line 42: Error: #error "Use of<stdbool.h> is valid 
> only in a c99 compilation environment.".
> gmake[1]: *** [Makefile:8174: src/devices/grodvi/dvi.o] Error 1

Ah, I didn't catch this on gcc210.fsffrance.org because I used only the
host's default environment, which does not have the Sun compilers, so
gcc gets found.

> This could be worked around by Gnulib, see
> https://www.gnu.org/software/gnulib/manual/html_node/stdbool_002eh.html
> but groff's bootstrap.conf does not request the Gnulib module
> 'stdbool-c99'.

Right.  That was deliberate (for the same reason we had our own
"assert.h"), but the reason for the choice has evaporated; we can't
support ISO C90 (only) if we're using gnulib anyway.

So I will add 'stdbool-c99' to our bootstrap.conf.

> * The gcc, g++ compilers.
> 
> In this configuration, the build succeeded, but there were 150 test
> failures.  Log attached. Most of the failures are caused by use of
> $(...) which is OK according to POSIX, but the Solaris 10 /bin/sh is
> not POSIX compliant.

These were known to me.  I have added information to the release
announcement template and to our PROBLEMS file at the top of the source
tree.  Here's the text.  I mention some other problems too in case you
have comments/corrections--I infer that you are a more practiced porter
than I am.  :)

Caveats
=======

o GNU tools, or otherwise POSIX-conforming ones, are generally required
  to build on Solaris 10 or 11.  See the "PROBLEMS" file in the
  distribution archive.

o A failure in automated testing occurs (if you run "make check") for
  gdiffmk if GNU diffutils 3.9 is used.  This is a known problem with
  that release; see <https://debbugs.gnu.org/db/61/61193.html>.

o Solaris 10 has known problems with automated tests; see the "PROBLEMS"
  file in the distribution archive.

o There is a problem building on "newlib"-using systems when X11 support
  is enabled; see the "PROBLEMS" file in the distribution archive.

...

----------------------------------------------------------------------

* I get a make(1) failure involving grep and the groff_man.7.man.in file
  on Solaris 11.

Solaris make(1) has a bug easily exhibited by the following Makefile.

all:
        ! false

Use GNU make instead; it may be available in /opt/csw/bin/gmake.

----------------------------------------------------------------------

* The "check-default-foundry" test fails when I run "make check".

Your Ghostscript installation may have its fonts embedded in the
executable; this can be discerned by searching for the pattern "%rom%"
in its search path.

  $ gs -h | grep '%rom%'

The consequence is that gropdf(1) will be unable to embed fonts into PDF
files it generates (apart from groff's "EURO" font) when the default
foundry is used.  This is the same outcome as if Ghostscript were not
installed at all.  If you install URW fonts (see "INSTALL.extra"), you
will be able to embed them all by using the "U" foundry with gropdf to
overcome this problem.

----------------------------------------------------------------------

* Tests fail when I run "make check" on Solaris 10 or 11.

The test suite expects a POSIX-conforming shell and utilities.  Solaris
10 does not offer these in the default $PATH.  We try to use features
standardized no later than POSIX Issue 4 (1994).  Unfortunately even
that is too recent for some implementations.  Solaris 11 has a (mostly)
conforming shell.  It may help to ensure that "/usr/xpg6/bin" and
"/usr/xpg4/bin" precede "/usr/bin" in the $PATH when building groff.

For Solaris 10, it is necessary to modify the shell-based test scripts
in place to use a conforming shell.  Here is an example.

  $ gsed -i -e '1s@#!/bin/sh@#!/usr/xpg4/bin/sh@' \
      `find . -name '*.sh' | grep /tests/`
  $ PATH=/usr/xpg4/bin:$PATH gmake check

Some test failures remain expected on Solaris 10.

1.  FAIL: tmac/tests/pdfpic_does-not-choke-on-bad-pdfinfo-output.sh

    /usr/bin/sed is non-conforming with the POSIX Issue 4 standard.

    Install GNU sed in the $PATH and edit tmac/pdfpic.tmac and change
    the "sed" on line 172 to "gsed".  Re-run "gmake check" as above.

    The sed in /usr/xpg4/bin also works, but pdfpic.tmac uses groff's
    `sy` request, which wraps the standard C library `system()`
    function, which sanitizes $PATH to avoid privilege escalation, thus
    making it likely that the non-conforming sed in /usr/bin will be
    found first.

2.  FAIL: contrib/hdtbl/examples/test-hdtbl.sh

    /usr/bin/tr is non-conforming with the POSIX Issue 4 standard.  It
    furthermore issues anonymous diagnostics, saying only "Bad string".

    Install tr from GNU coreutils in the $PATH.  Edit line 57 of each of
    contrib/hdtbl/examples/fonts_x.in and
    contrib/hdtbl/examples/fonts_n.in.  Change "tr" to "gtr".  Re-run
    "gmake check" as above.  (Some files will be rebuilt.)

    The tr commands in /usr/xpg4/bin and /usr/xpg6/bin also work, but
    the documents constructed from the above inputs use groff's `pso`
    request, which wraps the standard C library `popen()` function,
    which sanitizes $PATH to avoid privilege escalation, thus making it
    likely that the non-conforming tr in /usr/bin will be found first.

3.  FAIL: src/roff/groff/tests/initialization_is_quiet.sh
    FAIL: src/roff/groff/tests/msoquiet_works.sh
    FAIL: src/roff/groff/tests/soquiet_works.sh

    /usr/xpg4/bin/sh is non-conforming with the POSIX Issue 4 standard,
    despite its name.  Its "unset" builtin is buggy.

    These tests use the "unset" shell builtin command to prevent
    environment variables from confounding test results.

    POSIX says "[u]nsetting a variable ... that was not previously set
    is not considered an error and will not cause the shell to abort."

    Nevertheless this builtin returns an error exit status in this
    circumstance.

    $ /usr/xpg4/bin/sh -c 'unset _NON_EXISTENT_XYZ; echo $?'
    1

    You may disregard these failures, edit the test scripts to append
    "|| true" to the "unset" commends, or change the scripts to use GNU
    Bash or some other POSIX-conforming shell as illustrated above.

----------------------------------------------------------------------

* I get a build failure on Cygwin / a system using newlib and GCC 11.

  "newlib" defines a function called "utoa" which conflicts with a
  static (file scope-local) function in src/libs/libxutil/XFontName.c.

  We expect to fix this in the near future; in the meantime, you can
  patch the file to rename the function (and update its call sites) or,
  if you don't require the "gxditview" output previewer or "xtotroff"
  utility, you can build groff without X11 support.

  $ make distclean
  $ ./configure --without-x

Regards,
Branden

signature.asc
Description: PGP signature