GCC 4.8 support is broken

[dmoody256]

Building with GCC 4.8 on Ubuntu 14 is broken after this commit:
2376867

The build will error out:
./autogen.sh && make

producing errors similar to this:

make[4]: Entering directory `/home/daniel/harfbuzz/repo/src'
  CXX      libharfbuzz_la-hb-aat-layout.lo
In file included from hb.hh:651:0,
                 from hb-open-type.hh:32,
                 from hb-aat-layout.cc:28:
hb-algs.hh: In instantiation of 'decltype (hb_partial<2>(this, hb_forward<_T>(_v)))<anonymous struct>::operator()(_T&&) const [with _T = const OT::RuleSet* const; decltype (hb_partial<2>(this, hb_forward<_T>(_v))) = hb_partial_t<2u, const<anonymous struct>* const&, const OT::RuleSet* const>]':
hb-ot-layout-gsubgpos.hh:1374:27:   required from here
hb-meta.hh:68:56: error: could not convert 'hb_partial<2u, const<anonymous struct>* const, const OT::RuleSet* const>((* & this), (* & hb_forward<const OT::RuleSet* const>((* & _v))))' from 'hb_partial_t<2u, const<anonymous struct>* const, const OT::RuleSet* const>' to 'hb_partial_t<2u, const<anonymous struct>* const&, const OT::RuleSet* const>'
 #define HB_AUTO_RETURN(E) -> decltype ((E)) { return (E); }
                                                        ^
hb-algs.hh:164:36: note: in expansion of macro 'HB_AUTO_RETURN'
   auto operator () (_T&& _v) const HB_AUTO_RETURN (hb_partial<Pos> (this, hb_forward<_T> (_v))) \
                                    ^
hb-algs.hh:831:3: note: in expansion of macro 'HB_PARTIALIZE'
 { HB_PARTIALIZE(2);
   ^

previous commit is working:
6f51e55

[behdad]

Umm. Was hoping we can drop gcc 4.9... I'll see if I can debug and bring it back.

@ebraminio maybe we should put back the old gcc in Travis...

[behdad]

That error is so nonsensical. I'm not sure if I can fix it.

[behdad]

Okay found a gcc 4.9. Debugging.

[dmoody256]

FYI, I don't have a particular need for GCC 4.8. So if it is planned to be not supported, that is fine with me. Maybe other users will care?

Just please mention GCC support in the docs or notes somewhere.

[behdad]

gcc (Debian 4.9.2-10+deb8u2) 4.9.2 seems to work for me. 4.8 umm. I don't have. How critical you find this?

[behdad]

Thanks. I'll mention in the release notes for next release.

[dmoody256]

Also if you ever want to reproduce it, travis has GCC 4.8 in trusty:
https://travis-ci.org/dmoody256/harfbuzz-1/jobs/536848385

[behdad]

Thanks. We had that bot and removed it indeed. Without a local reproduction setup I cannot fix. It's too much trial-and-error to do remotely.

[ebraminio]

@ebraminio maybe we should put back the old gcc in Travis...

we can bring back trusty builder maybe in CircleCI so you can log into it whenever needed but maybe we can update our compiler requirement, nodejs needs GCC 6.3 for example https://github.com/nodejs/node/blob/master/BUILDING.md#supported-toolchains

[behdad]

This seems to point to the bug affecting gcc 4.8:
https://stackoverflow.com/a/20021858

Note that we are hitting a similar problem with multiple (more recent) versions of Visual Studio:
#1730

[ebraminio]

So have you fixed it with VS fixes?

[behdad]

So have you fixed it with VS fixes?

No, the VS workaround requires C++14 and is guarded for MSVC only.

[khaledhosny]

TeX Live seems to require building with GCC 4.8, so this issue is affecting their builds.

[kberry]

Following up with more details from Khaled's post ... gcc 4.8.5 (with lots of enhancements -- don't know what the compiler really supports and what it doesn't, due to Red Hat's crazy version number policy) is what is provided by centos 7, whose end-of-life is not until 2024. So ... is it really necessary to use C++ features that it does not support? All previous versions of harfbuzz compiled ok on centos7.

I can certainly arrange for access to such a system for you if that is needed.

In TeX Live, harfbuzz is a critical dependency of the xetex and (new) harftex engines, among other packages. In TL, we try to ship binaries that will work on as many systems as possible. Which means compiling on older systems, with older compilers. Updating either systems or compilers is not desirable.

Thanks.

[hmenke]

I quickly bisected this: 2376867
But this is only the first of many others. The real problem is that this is obviously a bug in GCC.

[behdad]

So ... is it really necessary to use C++ features that it does not support?

That's not a productive point to discuss. If we let every single compiler's limitations to hold us back, we can never modernize our codebase...

I can certainly arrange for access to such a system for you if that is needed.

Yes please do that. I can look into a workaround.

[behdad]

Thanks @kberry. Should be fixed. Please test.

[kberry]

indeed, it worked for me with centos7 gcc/g++. thank you so much.