failure to build: base class 'class ts::StringifyInterface' should be explicitly initialized in the copy constructor [-Werror=extra]

barsnick commented 1 year ago

Bug description:

When building with g++-8.5, the mentioned error occurs. (I assume the error would be a warning without -Werror?) No problems occur with newer compilers (g++-11.4 and up, on CentOS9, Fedora 37/38/39/Rawhide).

How to reproduce:

Fedora infrastructure COPR, running EPEL8 in a mock infrastructure, using packages from rhel-baseos, rhel-appstream, epel. Notably gcc, g++:

gcc                           x86_64  8.5.0-18.el8                   rhel-appstream   23 M
gcc-c++                       x86_64  8.5.0-18.el8                   rhel-appstream   12 M

Build using

/usr/bin/make -O -j2 NOTEST=true SYSPREFIX=/usr ETCDIR=/etc USRLIBDIR=/usr/lib64 UDEVDIR=/usr/lib/udev/rules.d NODEKTEC=true NOVATEK=true

Expected behavior:

Compiles successfully.

Errors and logs:

base/xml/tsxmlDocument.cpp: In copy constructor 'ts::xml::Document::Document(const ts::xml::Document&)':
base/xml/tsxmlDocument.cpp:49:1: error: base class 'class ts::StringifyInterface' should be explicitly initialized in the copy constructor [-Werror=extra]
 ts::xml::Document::Document(const Document& other) :
 ^~

Environment:

OS: Linux
OS version: EPEL8
TSDuck full version: 3.35-3258
Installation type: building from released source package

Additional information:

Building in a Fedora COPR: https://copr.fedorainfracloud.org/coprs/barsnick/tsduck/

For all I know, building with EPEL8 may fail at a later stage. Perhaps someone should try make -k in a Docker. At least I was able to provide all dependencies (see that COPR repo).

I have no "build root" systems with compilers between versions 8.5 and 11.4 to test with.

I am aware that I am (not) yet complying to the packaging rules set up in https://tsduck.io/doxy/building.html. That should have no impact whatsoever on the compilation.

lelegard commented 1 year ago

Hi @barsnick

This is a bug in GCC 8.5.0.

I installed an RHEL8 VM which comes with this version of GCC and I got the error too.

GCC should not report this error. As you noted, the problem does no appear with other versions of GCC. So, the bug was fixed in GCC. Moreover, this bug is not even consistent because the exact same kind of structure exists in other TSDuck classes and GCC 8.5.0 complains on this one only, not on the others.

I have pushed a small workaround to make GCC 8.5.0 shut up. You may retry with the latest version of the repo (or apply the fix in commit b243fdb in your version of you prefer).

barsnick commented 1 year ago

Wow, thanks for figuring this out and the workaround. I did suspect something like a compiler bug or an insufficient C++ standard implementation.

It builds successfully now with this patch.

barsnick commented 1 year ago

Fixed in https://github.com/tsduck/tsduck/commit/b243fdbfc7ee04cc1bfb3fed5f129ed3ce9481e2

tsduck / tsduck