#1097500 odr-dabmod: ftbfs with GCC-15

#1097500#5
Date:
2025-02-17 17:41:01 UTC
From:
To:
[This bug is NOT targeted to the upcoming trixie release]

Please keep this issue open in the bug tracker for the package it
was filed for.  If a fix in another package is required, please
file a bug for the other package (or clone), and add a block in this
package. Please keep the issue open until the package can be built in
a follow-up test rebuild.

The package fails to build in a test rebuild on at least amd64 with
gcc-15/g++-15, but succeeds to build with gcc-14/g++-14. The
severity of this report will be raised before the forky release.

The full build log can be found at:
http://qa-logs.debian.net/2025/02/16/amd64exp/odr-dabmod_2.6.0+ds-1_unstable_gccexp.log.gz
The last lines of the build log are at the end of this report.

To build with GCC 15, either set CC=gcc-15 CXX=g++-15 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.

  apt-get -t=experimental install g++

GCC 15 now defaults to the C23/C++23 standards, exposing many FTBFS.
Other Common build failures are new warnings resulting in build failures
with -Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-15/porting_to.html

[...]
src/Buffer.cpp:62:41: error: template argument 2 is invalid
src/Buffer.cpp: In constructor ‘Buffer::Buffer(const int&)’:
src/Buffer.cpp:69:17: error: request for member ‘data’ in ‘vec’, which is of non-class type ‘const int’
   69 |     setData(vec.data(), vec.size());
      |                 ^~~~
src/Buffer.cpp:69:29: error: request for member ‘size’ in ‘vec’, which is of non-class type ‘const int’
   69 |     setData(vec.data(), vec.size());
      |                             ^~~~
src/Buffer.cpp: At global scope:
src/Buffer.cpp:114:45: error: ‘uint8_t’ was not declared in this scope
  114 | Buffer& Buffer::operator=(const std::vector<uint8_t>& buf)
      |                                             ^~~~~~~
src/Buffer.cpp:114:45: note: ‘uint8_t’ is defined in header ‘<cstdint>’; this is probably fixable by adding ‘#include <cstdint>’
src/Buffer.cpp:114:52: error: template argument 1 is invalid
  114 | Buffer& Buffer::operator=(const std::vector<uint8_t>& buf)
      |                                                    ^
src/Buffer.cpp:114:52: error: template argument 2 is invalid
src/Buffer.cpp: In member function ‘Buffer& Buffer::operator=(const int&)’:
src/Buffer.cpp:116:17: error: request for member ‘data’ in ‘buf’, which is of non-class type ‘const int’
  116 |     setData(buf.data(), buf.size());
      |                 ^~~~
src/Buffer.cpp:116:29: error: request for member ‘size’ in ‘buf’, which is of non-class type ‘const int’
  116 |     setData(buf.data(), buf.size());
      |                             ^~~~
src/Buffer.cpp: At global scope:
src/Buffer.cpp:155:1: error: ‘uint8_t’ does not name a type
  155 | uint8_t Buffer::operator[](size_t i) const
      | ^~~~~~~
src/Buffer.cpp:155:1: note: ‘uint8_t’ is defined in header ‘<cstdint>’; this is probably fixable by adding ‘#include <cstdint>’
make[2]: *** [Makefile:1115: src/odr_dabmod-Buffer.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [Makefile:1143: src/odr_dabmod-ModPlugin.o] Error 1
In file included from src/ModPlugin.h:33,
                 from src/DabModulator.h:38,
                 from src/DabModulator.cpp:31:
src/Buffer.h:50:34: error: ‘uint8_t’ was not declared in this scope
   50 |         Buffer(const std::vector<uint8_t>& vec);
      |                                  ^~~~~~~
src/Buffer.h:36:1: note: ‘uint8_t’ is defined in header ‘<cstdint>’; this is probably fixable by adding ‘#include <cstdint>’
   35 | #include <vector>
  +++ |+#include <cstdint>
   36 | #include <memory>
src/Buffer.h:50:41: error: template argument 1 is invalid
   50 |         Buffer(const std::vector<uint8_t>& vec);
      |                                         ^
src/Buffer.h:50:41: error: template argument 2 is invalid
src/Buffer.h:63:45: error: ‘uint8_t’ was not declared in this scope
   63 |         Buffer& operator=(const std::vector<uint8_t>& buf);
      |                                             ^~~~~~~
src/Buffer.h:63:45: note: ‘uint8_t’ is defined in header ‘<cstdint>’; this is probably fixable by adding ‘#include <cstdint>’
src/Buffer.h:63:52: error: template argument 1 is invalid
   63 |         Buffer& operator=(const std::vector<uint8_t>& buf);
      |                                                    ^
src/Buffer.h:63:52: error: template argument 2 is invalid
src/Buffer.h:65:9: error: ‘uint8_t’ does not name a type
   65 |         uint8_t operator[](size_t i) const;
      |         ^~~~~~~
src/Buffer.h:65:9: note: ‘uint8_t’ is defined in header ‘<cstdint>’; this is probably fixable by adding ‘#include <cstdint>’
make[2]: *** [Makefile:1101: src/odr_dabmod-DabModulator.o] Error 1
In file included from src/ConfigParser.cpp:35:
lib/INIReader.h: In function ‘int ini_parse_stream(ini_reader, void*, ini_handler, void*)’:
lib/INIReader.h:181:12: warning: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ output may be truncated copying 49 bytes from a string of length 199 [-Wstringop-truncation]
  181 |     strncpy(dest, src, size - 1);
      |            ^
make[2]: Leaving directory '/build/reproducible-path/odr-dabmod-2.6.0+ds'
make[1]: *** [Makefile:664: all] Error 2
make[1]: Leaving directory '/build/reproducible-path/odr-dabmod-2.6.0+ds'
dh_auto_build: error: make -j8 returned exit code 2
make: *** [debian/rules:6: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

#1097500#14
Date:
2025-09-19 09:37:12 UTC
From:
To:
Sorry, my previous message was sent from the wrong e-mail account.
Here it is again:
--- Hi Matthias, odr-dabmod is now available as version 3.0.1+ds-1 in unstable and testing. Is this bug still applicable ? Thanks. Robin
#1097500#19
Date:
2025-09-19 09:34:27 UTC
From:
To:
Hi Matthias,

odr-dabmod is now available as version 3.0.1+ds-1 in unstable and
testing.

Is this bug still applicable ?

Thanks.

Robin