[bluez/bluez] 560147: configure.ac: check for stdarg.h

[bluez/bluez] 560147: configure.ac: check for stdarg.h

[Pauli Virtanen]

  Branch: refs/heads/master
  Home:   https://github.com/bluez/bluez
  Commit: 56014755a3e7df37056cf5efff8732e698fd4124
      https://github.com/bluez/bluez/commit/56014755a3e7df37056cf5efff8732e698fd4124
  Author: Til Kaiser <mail@tk154.de>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M configure.ac

  Log Message:
  -----------
  configure.ac: check for stdarg.h

Currently, there is the following compile error while
building with -std=gnu23, which is now default for GCC 15:

src/shared/shell.c: In function 'rl_cleanup':
src/shared/shell.c:1435:9: error: too many arguments to function 'rl_message'; expected 0, have 2
 1435 |         rl_message("%s", "");
      |         ^~~~~~~~~~ ~~~~
In file included from src/shared/shell.c:29:
/usr/include/readline/readline.h:410:12: note: declared here
  410 | extern int rl_message ();
      |            ^~~~~~~~~~

This adds a check for stdarg.h inside the configure script so that
HAVE_STDARG_H gets defined and the correct prototype is picked
from readline.h.


  Commit: ae1b7f6ba805f82742bbc32ff275e268248ef9f8
      https://github.com/bluez/bluez/commit/ae1b7f6ba805f82742bbc32ff275e268248ef9f8
  Author: Pauli Virtanen <pav@iki.fi>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M src/shared/bap.c

  Log Message:
  -----------
  shared/bap: handle inverted order of stop ready and disabling->qos

DISABLING->QOS transition and Receiver Stop Ready reply may arrive in
any order.  BAP v1.0.2 (Sec. 5.6.5.1): CIS may be terminated by either
side after Receiver Stop Ready has successfully completed.  However,
when we get the reply, the stream may be in either state.

Instead of client detaching the IO on stop ready reply, rely on
detaching IO on entering QOS, where Receiver Stop Ready has then
necessarily completed. On DISABLING, mark stream io as not connecting,
so that it gets detached even if CIS was not yet established.

Seen to occur with Samsung Galaxy Buds2 Pro, when it refuses Enable for
32/32kHz duplex on one of the earbuds.


Compare: https://github.com/bluez/bluez/compare/01f3ef3cd9d6...ae1b7f6ba805

To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications