YosysHQ/nextpnr

nextpnr fails to build using g++ version 14.0.1 (fedora)

gsomlo opened this issue · 2 comments

gsomlo commented

When building nextpnr with g++ version 14.0.1 (e.g. in the upcoming Fedora 40), the build fails with the following error:

In file included from /builddir/build/BUILD/nextpnr-2afb1f632e3069c140c1a7619031e9bda20d2002/redhat-linux-build/generated/gui/generic/gui_generic_autogen/EWIEGA46WW/../../../../../../gui/fpgaviewwidget.h:39,
                 from /builddir/build/BUILD/nextpnr-2afb1f632e3069c140c1a7619031e9bda20d2002/redhat-linux-build/generated/gui/generic/gui_generic_autogen/EWIEGA46WW/moc_fpgaviewwidget.cpp:10,
                 from /builddir/build/BUILD/nextpnr-2afb1f632e3069c140c1a7619031e9bda20d2002/redhat-linux-build/generated/gui/generic/gui_generic_autogen/mocs_compilation.cpp:5:
/builddir/build/BUILD/nextpnr-2afb1f632e3069c140c1a7619031e9bda20d2002/redhat-linux-build/generated/gui/generic/gui_generic_autogen/EWIEGA46WW/../../../../../../gui/quadtree.h: In member function ‘nextpnr_generic::QuadTreeNode<CoordinateT, ElementT>& nextpnr_generic::QuadTreeNode<CoordinateT, ElementT>::operator=(nextpnr_generic::QuadTreeNode<CoordinateT, ElementT>&&)’:
/builddir/build/BUILD/nextpnr-2afb1f632e3069c140c1a7619031e9bda20d2002/redhat-linux-build/generated/gui/generic/gui_generic_autogen/EWIEGA46WW/../../../../../../gui/quadtree.h:228:20: error: assignment of read-only member ‘nextpnr_generic::QuadTreeNode<CoordinateT, ElementT>::max_elems_’
  228 |         max_elems_ = other.max_elems_;
      |         ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~

Apparently, the latest g++ thinks that the line in question doesn't "square" with the declaration of max_elems_ as const, here.

Here's the full fedora rawhide (40) build log for completeness.

Any clue as to how best to fix this much appreciated (hope it's an easy fix :) )

Hopefully 4220ce1 is enough, although I don't have a quick way of testing this.

gsomlo commented

I've started testing the exact same change right after filing the bug, seems to build fine in rawhide. I simply wasn't comfortable enough with c++ to authoritatively suggest that as an "official" change (the "smarter" the language, the less likely that the "obvious" hack is also the "correct" one :D )