Harfbuzz 2.3.0 broken on Solaris 10

[mojca]

I noticed the following problem in a TeX Live build immediately after it switched to 2.3.0, the previous version 2.2.0 worked fine. The compiler used was gcc 5.5 from OpenCSW. The same issue is present in a standalone build, on both sparc and i386/x86_64 Solaris:

gmake  all-recursive
gmake[1]: Entering directory '/path/to/harfbuzz-2.3.0'
Making all in src
gmake[2]: Entering directory '/path/to/harfbuzz-2.3.0/src'
gmake  all-recursive
gmake[3]: Entering directory '/path/to/harfbuzz-2.3.0/src'
Making all in hb-ucdn
gmake[4]: Entering directory '/path/to/harfbuzz-2.3.0/src/hb-ucdn'
  CC       libhb_ucdn_la-ucdn.lo
  CCLD     libhb-ucdn.la
gmake[4]: Leaving directory '/path/to/harfbuzz-2.3.0/src/hb-ucdn'
gmake[4]: Entering directory '/path/to/harfbuzz-2.3.0/src'
  CXX      libharfbuzz_la-hb-aat-layout.lo
In file included from hb-aat-layout.cc:28:0:
hb-open-type.hh: In instantiation of 'struct OT::IntType<char, 1u>':
hb-ot-layout-common.hh:1713:32:   required from here
hb-open-type.hh:64:72: error: incomplete type 'hb_is_signed<char>' used in nested name specifier
   typedef typename hb_signedness_int<hb_is_signed<Type>::value>::value wide_type;
                                                                        ^
In file included from hb-aat-layout-morx-table.hh:32:0,
                 from hb-aat-layout-just-table.hh:32,
                 from hb-aat-layout.cc:36:
hb-ot-layout-common.hh: In member function 'float OT::VarData::get_delta(unsigned int, const int*, unsigned int, const OT::VarRegionList&) const':
hb-ot-layout-common.hh:1713:22: error: no match for 'operator*' (operand types are 'float' and 'const HBINT8 {aka const OT::IntType<char, 1u>}')
      delta += scalar * *bcursor++;
                      ^

I wanted to check if it worked immediately before the commit 11d2f49, but I have issues getting autotools to work correctly.

[mojca]

I tried to test an older version, but it's a bit challenging since the autogenerated stuff is missing from the repository:

gtk-doc.make:7: error: GTK_DOC_USE_LIBTOOL does not appear in AM_CONDITIONAL
docs/Makefile.am:103:   'gtk-doc.make' included from here
src/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
test/api/Makefile.am:58: warning: variable 'test_subset_codepoints_LDADD' is defined but no program or
test/api/Makefile.am:58: library has 'test_subset_codepoints' as canonical name (possible typo)
test/subset/data/Makefile.am:8: warning: EXTRA_DIST multiply defined in condition TRUE ...
test/subset/data/Makefile.am:4: ... 'EXTRA_DIST' previously defined here
autoreconf: /opt/csw/bin/automake failed with exit status: 1

When using the pregenerated files, there are still some strange things when running configure:

checking whether make supports nested variables... yes
id: illegal option -- u
Usage: id [-ap] [user]
id: illegal option -- g
Usage: id [-ap] [user]
checking whether UID 'unknown' is supported by ustar format... ./configure: line 3534: test: unknown: integer expression expected
no
checking whether GID 'unknown' is supported by ustar format... ./configure: line 3544: test: unknown: integer expression expected
no
checking how to create a ustar tar archive... none
/.../
checking for gtk-doc... no
configure: WARNING:
  You will not be able to create source packages with 'make dist'
  because gtk-doc >= 1.15 is not found.
checking for gtkdoc-check... no
/.../
checking for ICU by using icu-config fallback... yes
./configure: line 20557: --variable=CXXFLAGS: command not found
checking for FREETYPE... no

[behdad]

@prrace can you help here?

[ebraminio]

Hmm we have older than this GCCs, do you think we can have a cross compiler similar to this on a x86-64 machine and preferably put it on some docker image for our CI use? (I mean we need just need a .dockerflie for the compiler in order to fix and always assert work-ability for the environment)

[mojca]

I just wanted to say that I tested gcc 5.5 on macOS and there it seems to compile just fine. So it cannot be just the compiler version. The same problem can be reproduced on OpenIndiana (version 11, I believe) with gcc 6.4. I don't know enough of C++ to understand what precisely the issue is here. What cross-compiler / host-target OS did you have in mind?

(You may also try to ask OpenCSW to set up a buildbot instance to test the builds on Solaris 10 or 11 in their build farm.)

[prrace]

We at OpenJDK have never used gcc to build on Solaris .. policy has always
been to build using Oracle Studio on Solaris, Visual Studio on Windows, Xcode on MacOS ..
and so forth, so if this is specific to gcc I don't think I'll be able to help, except to
double-check the findings and see if 2.3 is building OK with Oracle Studio which
I expect it is since I was building tip only a matter of days before the 2.3 release.

[mojca]

Does using Oracle Studio mean export CC=cc export CXX=CC? With that one I first get

configure: WARNING: stdbool.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: stdbool.h: proceeding with the compiler's result

followed by

  CXX      libharfbuzz_la-hb-aat-layout.lo
"hb-aat-layout.h", line 89: Warning: Identifier expected instead of "}".
"hb-aat-layout.h", line 428: Warning: Identifier expected instead of "}".
"hb-array.hh", line 196: Warning: Identifier expected instead of "}".
"hb-shaper.hh", line 67: Warning: Identifier expected instead of "}".
"hb-unicode.hh", line 218: Warning: Identifier expected instead of "}".
"hb-buffer.hh", line 78: Warning: Identifier expected instead of "}".
"hb-ot-face.hh", line 107: Warning: Identifier expected instead of "}".
"hb-open-type.hh", line 137: Error: __func__ is not defined.
"hb-open-type.hh", line 872: Error: __func__ is not defined.
"hb-aat-layout-common.hh", line 472: Error: __func__ is not defined.
"hb-aat-fdsc-table.hh", line 62: Error: __func__ is not defined.
"hb-aat-fdsc-table.hh", line 107: Error: __func__ is not defined.
"hb-aat-layout-ankr-table.hh", line 47: Error: __func__ is not defined.
"hb-aat-layout-ankr-table.hh", line 83: Error: __func__ is not defined.
"hb-aat-layout-bsln-table.hh", line 45: Error: __func__ is not defined.
"hb-aat-layout-bsln-table.hh", line 64: Error: __func__ is not defined.
"hb-aat-layout-bsln-table.hh", line 81: Error: __func__ is not defined.
"hb-aat-layout-bsln-table.hh", line 104: Error: __func__ is not defined.
"hb-aat-layout-bsln-table.hh", line 125: Error: __func__ is not defined.
"hb-aat-layout-bsln-table.hh", line 129: Error: __func__ is not defined.
"hb-aat-layout-bsln-table.hh", line 130: Error: __func__ is not defined.
"hb-aat-layout-bsln-table.hh", line 131: Error: __func__ is not defined.
"hb-aat-layout-bsln-table.hh", line 132: Error: __func__ is not defined.
"hb-aat-layout-bsln-table.hh", line 133: Error: __func__ is not defined.
"hb-aat-layout-feat-table.hh", line 66: Error: __func__ is not defined.
"hb-aat-layout-feat-table.hh", line 137: Error: __func__ is not defined.
"hb-aat-layout-feat-table.hh", line 200: Error: __func__ is not defined.
"hb-ot-layout-common.hh", line 166: Error: __func__ is not defined.
"hb-ot-layout-common.hh", line 236: Error: __func__ is not defined.
"hb-ot-layout-common.hh", line 243: Error: __func__ is not defined.
"hb-ot-layout-common.hh", line 282: Error: __func__ is not defined.
"hb-ot-layout-common.hh", line 287: Error: __func__ is not defined.
Compilation aborted, too many Error messages.

But anyway, using that compiler is not an option for us since we compile the full TeX Live at once and there are simply waaaaaay to many libraries that don't build with it, and it's not feasible to request from each one of those project to add support (probably requiring quite extensive patches) for a dying OS.

The problematic commit (the one I suspect) was added on the 1st of December. So I would be curious to hear about your results, @prrace. Thanks in advance.

(Slightly sad because we need to stick with the super old version on macOS for now.)

[prrace]

This error reported above :
hb-open-type.hh:64:72: error: incomplete type 'hb_is_signed<char>' used in nested name specifier
typedef typename hb_signedness_int<hb_is_signed::value>::value wide_type;

also manifests on Solaris 11 using Oracle Developer Studio 12.6 (the latest version) :
harfbuzz/hb-open-type.hh", line 64: Error: The type "hb_is_signed<char>" is incomplete.

[prrace]

The Solaris compiler folks say this could (or should) have caused a problem with other compilers too.
To quote :

The hb_is_signed template is specialized for signed char and unsigned char (see hb-dsalgs.hh around line 300).
According to the C++ standard (https://wg21.link/std17) section 6.9.1
[basic.fundamental] p.1: "Plain char, signed char, and unsigned char are three distinct types",
so the compiler's seeking for the definition of hb_is_signed and doesn't find any
as the primary template is deliberately left undefined and the specialization
doesn't match any explicitly provided.

Adding this one line into hb-dsalgs.hh fixes it for me :
template <> struct hb_is_signed<char> { enum { value = false }; };

[mojca]

Thank you. I need

template <> struct hb_is_signed<char> { enum { value = false }; };

though. The above mentioned suggestion without an argument in <...> doesn't work for me (using gcc).

[prrace]

Sigh .. that text IS there (if you select edit) on my post but markdown swallowed it.
I'll edit it to escape those

[behdad]

We never try instantiating that with char though, only with uint8_t and int8_t. I supposed that's why other compilers are fine. Depends on what those types are defined to.

[behdad]

We never try instantiating that with char though, only with uint8_t and int8_t. I supposed that's why other compilers are fine. Depends on what those types are defined to.

So, declaring hb_is_signed to return false for char is problematic if char is actually signed and int8_t typedefed to char...

I can probably get rid of this thing completely...

[behdad]

I can, instead, just add specializations for int8_t, uint8_t, etc.

[prrace]

That makes sense and explains why it is platform-specific and seen with gcc + Oracle Studio compilers on Solaris

[behdad]

Okay, pushed something. Let's see what bots break.

[behdad]

Also. I'm going to merge the iter branch soon. It requires C++11 and some advanced use of templates for SFINAE. I really hope we can get that working for all compilers you care about soon. Input from your compiler team would be appreciated.

[behdad]

Also. I'm going to merge the iter branch soon. It requires C++11 and some advanced use of templates for SFINAE. I really hope we can get that working for all compilers you care about soon. Input from your compiler team would be appreciated.