[This bug is 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-14/g++-14, but succeeds to build with gcc-13/g++-13. The
severity of this report will be raised before the trixie release.

The full build log can be found at:
http://qa-logs.debian.net/2024/07/01/libmemcached-libmemcached-perl_1.001801+dfsg-4_unstable_gccexp.log
The last lines of the build log are at the end of this report.

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

  apt-get -t=experimental install g++

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-14/porting_to.html

[...]
libmemcached.c:3013:35: warning: cast from function call of type ‘NV’ {aka ‘double’} to non-matching type ‘long unsigned int’ [-Wbad-function-cast]
 3013 |         uint64_t        initial = (uint64_t)SvNV(ST(4));
      |                                   ^
libmemcached.c:3048:21: warning: cast from function call of type ‘NV’ {aka ‘double’} to non-matching type ‘long unsigned int’ [-Wbad-function-cast]
 3048 |             value = (uint64_t)SvNV(ST(6));
      |                     ^
libmemcached.c: In function ‘XS_Memcached__libmemcached_memcached_decrement_with_initial_by_key’:
libmemcached.c:3100:35: warning: cast from function call of type ‘NV’ {aka ‘double’} to non-matching type ‘long unsigned int’ [-Wbad-function-cast]
 3100 |         uint64_t        initial = (uint64_t)SvNV(ST(4));
      |                                   ^
libmemcached.c:3135:21: warning: cast from function call of type ‘NV’ {aka ‘double’} to non-matching type ‘long unsigned int’ [-Wbad-function-cast]
 3135 |             value = (uint64_t)SvNV(ST(6));
      |                     ^
libmemcached.c: In function ‘XS_Memcached__libmemcached_memcached_get’:
libmemcached.c:3217:33: warning: cast from function call of type ‘IV’ {aka ‘long int’} to non-matching type ‘enum memcached_return_t’ [-Wbad-function-cast]
 3217 |         error = (SvOK(ST(3))) ? (memcached_return)SvIV(ST(3)) : 0;
      |                                 ^
libmemcached.c: In function ‘XS_Memcached__libmemcached_memcached_get_by_key’:
libmemcached.c:3314:33: warning: cast from function call of type ‘IV’ {aka ‘long int’} to non-matching type ‘enum memcached_return_t’ [-Wbad-function-cast]
 3314 |         error = (SvOK(ST(4))) ? (memcached_return)SvIV(ST(4)) : 0;
      |                                 ^
libmemcached.c: In function ‘XS_Memcached__libmemcached_memcached_fetch’:
libmemcached.c:3538:33: warning: cast from function call of type ‘IV’ {aka ‘long int’} to non-matching type ‘enum memcached_return_t’ [-Wbad-function-cast]
 3538 |         error = (SvOK(ST(3))) ? (memcached_return)SvIV(ST(3)) : 0;
      |                                 ^
libmemcached.c: In function ‘XS_Memcached__libmemcached_memcached_strerror’:
libmemcached.c:3922:30: warning: cast from function call of type ‘IV’ {aka ‘long int’} to non-matching type ‘enum memcached_return_t’ [-Wbad-function-cast]
 3922 |         rc = (SvOK(ST(1))) ? (memcached_return)SvIV(ST(1)) : 0;
      |                              ^
libmemcached.c: In function ‘XS_Memcached__libmemcached_trace_level’:
/usr/lib/x86_64-linux-gnu/perl/5.38/CORE/handy.h:155:23: warning: cast from function call of type ‘long int’ to non-matching type ‘_Bool’ [-Wbad-function-cast]
  155 | #define cBOOL(cbool) ((bool) (cbool))
      |                       ^
/usr/lib/x86_64-linux-gnu/perl/5.38/CORE/perl.h:4231:62: note: in definition of macro ‘EXPECT’
 4231 | #  define EXPECT(expr,val)                  __builtin_expect(expr,val)
      |                                                              ^~~~
/usr/lib/x86_64-linux-gnu/perl/5.38/CORE/perl.h:4251:52: note: in expansion of macro ‘cBOOL’
 4251 | #define LIKELY(cond)                        EXPECT(cBOOL(cond),TRUE)
      |                                                    ^~~~~
/usr/lib/x86_64-linux-gnu/perl/5.38/CORE/pp.h:429:13: note: in expansion of macro ‘LIKELY’
  429 |         if (LIKELY(                                                     \
      |             ^~~~~~
/usr/lib/x86_64-linux-gnu/perl/5.38/CORE/perl.h:996:34: note: in expansion of macro ‘cBOOL’
  996 | #   define TAINT_get            (cBOOL(UNLIKELY(PL_tainted)))    /* Is something tainted? */
      |                                  ^~~~~
/usr/lib/x86_64-linux-gnu/perl/5.38/CORE/pp.h:431:28: note: in expansion of macro ‘TAINT_get’
  431 |             & (do_taint ? !TAINT_get : 1)))                             \
      |                            ^~~~~~~~~
/usr/lib/x86_64-linux-gnu/perl/5.38/CORE/pp.h:495:38: note: in expansion of macro ‘TARGi’
  495 | #define PUSHi(i)        STMT_START { TARGi(i,1); PUSHs(TARG); } STMT_END
      |                                      ^~~~~
libmemcached.c:4001:20: note: in expansion of macro ‘PUSHi’
 4001 |         XSprePUSH; PUSHi((IV)RETVAL);
      |                    ^~~~~
libmemcached.c: In function ‘XS_Memcached__libmemcached_mget_into_hashref’:
libmemcached.c:4230:46: warning: comparison of constant ‘12’ with boolean expression is always false [-Wbool-compare]
 4230 |     if (!SvROK(ST(2)) || !SvTYPE(SvRV(ST(2)))==SVt_PVHV)
      |                                              ^~
libmemcached.c:4230:46: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
libmemcached.c:4230:26: note: add parentheses around left hand side expression to silence this warning
 4230 |     if (!SvROK(ST(2)) || !SvTYPE(SvRV(ST(2)))==SVt_PVHV)
libmemcached.c: In function ‘boot_Memcached__libmemcached’:
libmemcached.c:4613:23: error: assignment to ‘I32’ {aka ‘int’} from ‘char *’ makes integer from pointer without a cast [-Wint-conversion]
 4613 |         XSANY.any_i32 = MEMCACHED_DEFAULT_PORT_STRING ;
      |                       ^
make[1]: *** [Makefile:393: libmemcached.o] Error 1
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
dh_auto_build: error: make -j8 returned exit code 2
make: *** [debian/rules:13: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

From my current analysis, the relevant error is below:

It looks to stem from the fact that Perl XS expects the
MEMCACHED_DEFAULT_PORT_STRING to be an int.  I'm not sure what
triggers that code path.  For what it's worth the variable seems
to be defined as a string in the embedded copy at the location
debian/libmemcached/lib/Memcached/libmemcached/const_hash.pl:

	'MEMCACHED_DEFAULT_PORT_STRING' => 'defines'

But there is a high probability that I'm looking nowhere near
the right place to resolve the issue.  If I'm looking at the
right place, then there's a non-zero chance the build failure is
specific to the packaging.  I'm not sure how to move this issue
forward.  I'll pick lower hanging fruits in the meantime.

In hope this helps,

Yes, I think MEMCACHED_DEFAULT_PORT_STRING has always had a type mismatch.
With the current sid package:

# perl -MMemcached::libmemcached=:defines  -E 'say for (MEMCACHED_DEFAULT_PORT, MEMCACHED_DEFAULT_PORT_STRING)'
11211
-2128759247

The latter varies on each run as it's just the pointer to the underlying
string. It's clearly quite useless.

A quick fix is to remove MEMCACHED_DEFAULT_PORT_STRING from the
bundled debian/libmemcached/const-xs.inc. That makes the build pass for
me. Presumably the files in debian/libmemcached/lib/Memcached/libmemcached
would need a similar change to keep the documentation etc. in sync.

However, I wonder if we should really regenerate const-xs.inc et al. with
the Makefile.PL machinery on each build rather than use the hardcoded
list. I see the packaging has been this way from the start, but AFAICS
extract_libmemcached_functions() and extract_libmemcached_constants()
(which we're currently patching out) should work just fine with the
system headers too.

That would require special casing MEMCACHED_DEFAULT_PORT_STRING or
adding logic to skip string constants or whatever, but it would
seem cleaner to me.

But I guess that's a separate bug. Hope this helps anyway.

Thanks for looking at this,