[Bug build/34408] New: gdb gprofng fails to build on Arch Linux due to CALL_UTIL(strstr)

https://sourceware.org/bugzilla/show_bug.cgi?id=34408

            Bug ID: 34408
           Summary: gdb gprofng fails to build on Arch Linux due to
                    CALL_UTIL(strstr)
           Product: gdb
           Version: 17.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: build
          Assignee: unassigned at sourceware dot org
          Reporter: nyanpasu64 at tuta dot io
  Target Milestone: ---

When attempting to build gdb 17.2 based on the Arch Linux PKGBUILD flags, I
get:

../../../gprofng/libcollector/iolib.c: In function ‘is_not_the_log_file’:
../../../gprofng/libcollector/iolib.c:898:18: error: expected identifier before
‘_Generic’
  898 |   if (CALL_UTIL (strstr)(fname, SP_LOG_FILE) == NULL)
      |                  ^~~~~~
../../../gprofng/libcollector/iolib.c:898:7: note: in expansion of macro
‘CALL_UTIL’
  898 |   if (CALL_UTIL (strstr)(fname, SP_LOG_FILE) == NULL)
      |       ^~~~~~~~~

I traced this to CALL_UTIL expanding to `__collector_util_funcs.strstr`, and
attempting to call this expression. The problem is that in C23 mode, glibc's
headers has a const-correctness check:

extern char *strstr (const char *__haystack, const char *__needle)
     __THROW __attribute_pure__ __nonnull ((1, 2));
# if __GLIBC_USE (ISOC23) && defined __glibc_const_generic && !defined _LIBC
#  define strstr(HAYSTACK, NEEDLE)                      \
  __glibc_const_generic (HAYSTACK, const char *,        \
                         strstr (HAYSTACK, NEEDLE))
# endif

The problem is that this strstr macro trips on __collector_util_funcs.strstr()
and not just top-level calls.

- Is this a glibc bug in how they implemented C23 const-correctness?
- To workaround the bug, I found you could wrap the call into (CALL_UTIL
(strstr))(...) to prevent the resulting syntax from parsing as a strstr macro
call.
- As a cleaner alternative, I realized you could add the surrounding
parentheses in the CALL_UTIL macro definition, but have not tried compiling the
program with  these changes.
- Is gprofng *supposed* to build in C23 mode?
- Is this a gprofng bug rather than a gdb one?

-- 
You are receiving this mail because:
You are on the CC list for the bug.