https://github.com/libyui/libyui/blob/master/libyui/src/TreeItem.h#L49

>  33  /**
>  34   * Template class for tree items that can handle tree children in a
>  35   * generic way - firstChild(), next() and parent(). Each item stores one value
>  36   * of type 'PAYLOAD'.
>  37   *
>  38   * Class 'PAYLOAD' needs to provide operator=().
>  39   **/
>  40  template<class PAYLOAD> class TreeItem
>  41  {
>  42  public:
>  43  
>  44      /**
>  45       * Constructor. Creates a new tree item with value "val" and inserts it
>  46       * ( without maintaining any meaningful sort order! ) into the children list
>  47       * of "parent".
>  48       **/
>  49      TreeItem<PAYLOAD> ( const PAYLOAD &         val,
>  50                          TreeItem<PAYLOAD> *     parent = 0 )
>  51          : _value( val )
>  52          , _parent( parent )
>  53          , _next(0)
>  54          , _firstChild(0)
>  55      {
>  56          if ( _parent )
>  57              _parent->addChild( this );
>  58      }
>  59  
>  60  

What on earth is it complaining about now?
What did they introduce now to make a developer's life even harder?

> TreeItem.h:49:23: note: remove the ‘< >’

?!????

https://stackoverflow.com/questions/71978335/class-templates-constructor-declaration-doesnt-compile-for-c20-but-compiles

?!?

Looks like we should compile with the '-std=c++11' (or c++14 or c++17) option if they introduced incompatible standards like this in C++20.

See also

https://stackoverflow.com/questions/71978335/class-templates-constructor-declaration-doesnt-compile-for-c20-but-compiles

Draft PR (WIP):

https://github.com/libyui/libyui/pull/110

The missing quadmath.h problem is still there.

From /usr/include/boost/multiprecision/cpp_bin_float.hpp (which is owned by libboost_headers1_85_0-devel):

>>  #ifdef BOOST_HAS_FLOAT128
>>  #include <quadmath.h>
>>  #endif

Not sure if we can do anything about that from the YaST / libyui side.

Besides the compile error in FSize.cc that complains about the boost headers trying to include the nonexistent quadmath.h, the rest of all the subdirectories build fine.

The PR is now merged:

  https://github.com/libyui/libyui/pull/110

This will become available as libyui-16-4.6.2.

Notice that this does not include the quadmath.h problem which is very likely on the boost side.

Submitted manually to OBS:

  https://build.opensuse.org/request/show/1188131

Thank you very much for dealing with the warnings.

Because the package still fails, I'm re-opening the bug however but also assigning it to myself and will try to deal with the problematic include of quadmath.h.

(In reply to Stefan Hundhammer from comment #7)
> From /usr/include/boost/multiprecision/cpp_bin_float.hpp (which is owned by
> libboost_headers1_85_0-devel):
> 
> >>  #ifdef BOOST_HAS_FLOAT128
> >>  #include <quadmath.h>
> >>  #endif
> 
> Not sure if we can do anything about that from the YaST / libyui side.

Because of a bug[1] in GCC 13 and earlier versions, the #include of
quadmath.h in multiprecision/cpp_bin_float.hpp did not fail even when
the header file was not present on the system and compilation
succeeded as long as nothing from the header file was actually needed.

Examining this build failure, I noticed that in
math/special_functions/fpclassify.hpp (which is indirectly included
from multiprecision/cpp_bin_float.hpp) the existence of the header
file is specifically tested and macro BOOST_MATH_HAS_QUADMATH_H is
defined or not accordingly.  I have therefore asked upstream if the
same macro should not be used also here.

Meanwhile, as a workaround, I would simply like to add gcc-fotran as
another build requirement of the package, because that is where
quadmath.h is distributed.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80753

It seems upstream boost is receptive to addressing this on their end: https://lists.boost.org/Archives/boost/2024/07/257226.php