Fix binutils build on hppa64-hpux with gcc-16

  Okay?

Dave
---

Fix binutils build on hppa64-hpux with gcc-16

With gcc-16, implicit function declarations are errors.  We
need to ensure that ffs() and strtoull() are declared.

2025-11-30  John David Anglin  <danglin@gcc.gnu.org>

bfd/ChangeLog:

	* bfdio.c: Include libiberty.h.
	* configure.ac: Check for presence of long long type.  Check
	for strtoull declaration.
	* configure: Regenerate.
	* config.in: Regenerate.
	* strings.h: Include strings.h.

bfd/ChangeLog:

	* configure.ac: Check for presence of long long type.  Check
	for strtoull declaration.
	* configure: Regenerate.
	* config.in: Regenerate.
  

On 30.11.2025 18:27, John David Anglin wrote:
> --- a/bfd/configure.ac
> +++ b/bfd/configure.ac
> @@ -205,6 +205,11 @@ ZW_GNU_GETTEXT_SISTER_DIR
>  AC_SUBST(HDEFINES)
>  AC_PROG_INSTALL
>  
> +# Check for presense of long long
> +AC_CHECK_TYPE([long long],
> +  [AC_DEFINE(HAVE_LONG_LONG, 1, [Define if you have the `long long' type.])],
> +    [])

Why would this be needed? C99 guarantees existence of long long, doesn't it?

> --- a/bfd/sysdep.h
> +++ b/bfd/sysdep.h
> @@ -36,6 +36,7 @@
>  #include <stdlib.h>
>  #include <stddef.h>
>  #include <string.h>
> +#include <strings.h>

Iirc this isn't a standard header, and hence can't be included without being
sure it exists. Given the patch description it's also not clear to me what
the #include would be needed for.

Jan
  

On 2025-12-01 2:56 a.m., Jan Beulich wrote:
> On 30.11.2025 18:27, John David Anglin wrote:
>> --- a/bfd/configure.ac
>> +++ b/bfd/configure.ac
>> @@ -205,6 +205,11 @@ ZW_GNU_GETTEXT_SISTER_DIR
>>  AC_SUBST(HDEFINES)
>>  AC_PROG_INSTALL
>>  
>> +# Check for presense of long long
>> +AC_CHECK_TYPE([long long],
>> +  [AC_DEFINE(HAVE_LONG_LONG, 1, [Define if you have the `long long' type.])],
>> +    [])
> 
> Why would this be needed? C99 guarantees existence of long long, doesn't it?

It's needed because of the way libiberty.h declares strtoull().  hppa64-hpux lacks
strtoull(), so it's provided by libiberty.

> 
>> --- a/bfd/sysdep.h
>> +++ b/bfd/sysdep.h
>> @@ -36,6 +36,7 @@
>>  #include <stdlib.h>
>>  #include <stddef.h>
>>  #include <string.h>
>> +#include <strings.h>
> 
> Iirc this isn't a standard header, and hence can't be included without being
> sure it exists. Given the patch description it's also not clear to me what
> the #include would be needed for.

It's for ffs().

Linux has:

NAME
       ffs, ffsl, ffsll - find first bit set in a word

LIBRARY
       Standard C library (libc, -lc)

SYNOPSIS
       #include <strings.h>

       int ffs(int i);

and open group has:

NAME

    ffs - find first set bit

SYNOPSIS

    [XSI] #include <strings.h>

    int ffs(int i);

glibc implemented ffs() in glibc 2.12:

   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

       ffs():
           Since glibc 2.12:
               _XOPEN_SOURCE >= 700
                   || ! (_POSIX_C_SOURCE >= 200809L)
                   || /* glibc >= 2.19: */ _DEFAULT_SOURCE
                   || /* glibc <= 2.19: */ _BSD_SOURCE || _SVID_SOURCE
           Before glibc 2.12:
               none

Dave
  

On 01.12.2025 16:58, John David Anglin wrote:
> On 2025-12-01 2:56 a.m., Jan Beulich wrote:
>> On 30.11.2025 18:27, John David Anglin wrote:
>>> --- a/bfd/configure.ac
>>> +++ b/bfd/configure.ac
>>> @@ -205,6 +205,11 @@ ZW_GNU_GETTEXT_SISTER_DIR
>>>  AC_SUBST(HDEFINES)
>>>  AC_PROG_INSTALL
>>>  
>>> +# Check for presense of long long
>>> +AC_CHECK_TYPE([long long],
>>> +  [AC_DEFINE(HAVE_LONG_LONG, 1, [Define if you have the `long long' type.])],
>>> +    [])
>>
>> Why would this be needed? C99 guarantees existence of long long, doesn't it?
> 
> It's needed because of the way libiberty.h declares strtoull().  hppa64-hpux lacks
> strtoull(), so it's provided by libiberty.

With us requiring C99 now, can we even reliably run on a system not offering
(complete) C99 support?

>>> --- a/bfd/sysdep.h
>>> +++ b/bfd/sysdep.h
>>> @@ -36,6 +36,7 @@
>>>  #include <stdlib.h>
>>>  #include <stddef.h>
>>>  #include <string.h>
>>> +#include <strings.h>
>>
>> Iirc this isn't a standard header, and hence can't be included without being
>> sure it exists. Given the patch description it's also not clear to me what
>> the #include would be needed for.
> 
> It's for ffs().
> 
> Linux has:
> 
> NAME
>        ffs, ffsl, ffsll - find first bit set in a word
> 
> LIBRARY
>        Standard C library (libc, -lc)
> 
> SYNOPSIS
>        #include <strings.h>
> 
>        int ffs(int i);
> 
> and open group has:
> 
> NAME
> 
>     ffs - find first set bit
> 
> SYNOPSIS
> 
>     [XSI] #include <strings.h>
> 
>     int ffs(int i);
> 
> glibc implemented ffs() in glibc 2.12:
> 
>    Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
> 
>        ffs():
>            Since glibc 2.12:
>                _XOPEN_SOURCE >= 700
>                    || ! (_POSIX_C_SOURCE >= 200809L)
>                    || /* glibc >= 2.19: */ _DEFAULT_SOURCE
>                    || /* glibc <= 2.19: */ _BSD_SOURCE || _SVID_SOURCE
>            Before glibc 2.12:
>                none

Okay, but none of this make strings.h really standard. Wouldn't it again be
libiberty to cover for the differences (e.g. lack of ffs() decl) in such a
case?

Jan
  

On 2025-12-01 11:11 a.m., Jan Beulich wrote:
> Okay, but none of this make strings.h really standard. Wouldn't it again be
> libiberty to cover for the differences (e.g. lack of ffs() decl) in such a
> case?

ffs() is declared in strings.h in both hpux11 and glibc linux.  So, I don't
think this is a libiberty issue.

I would have thought this issue would affect glibc targets.  Have you tried
building binutils with gcc-16 or looking for a warning regarding the implicit
declaration of ffs()?

Maybe problem is hidden by gcc's __builtin_ffs() on targets with hardware support
for ffs.  Maybe would show if -fno-builtin is added to CFLAGS for build.

Dave
  

On 01.12.2025 18:12, John David Anglin wrote:
> On 2025-12-01 11:11 a.m., Jan Beulich wrote:
>> Okay, but none of this make strings.h really standard. Wouldn't it again be
>> libiberty to cover for the differences (e.g. lack of ffs() decl) in such a
>> case?
> 
> ffs() is declared in strings.h in both hpux11 and glibc linux.  So, I don't
> think this is a libiberty issue.

I didn't say it's a libiberty issue; I said libiberty might help addressing
the issue. Or else other configure machinery to determine whether strings.h
exists and actually contains what we're after. Recall that other, "less-GNU"
environments (think about the *BSD-s, for example, or see how there's
makefile.vms) also need to be covered (i.e. keep building).

That said, I notice bfd/elf32-xtensa.c includes strings.h unconditionally as
well. I'd similarly question this being legitimate.

> I would have thought this issue would affect glibc targets.  Have you tried
> building binutils with gcc-16 or looking for a warning regarding the implicit
> declaration of ffs()?

What I see is configure output like this

checking whether declaration is required for ffs... yes

and later

checking whether ffs is declared... yes

No compiler warnings. Instead bfd/sysdep.h already has

#if !HAVE_DECL_FFS
extern int ffs (int);
#endif

So is it perhaps the case that configure doesn't work correctly on hpux?

Jan
  

John David Anglin <dave.anglin@bell.net> writes:

> On 2025-12-01 11:11 a.m., Jan Beulich wrote:
>> Okay, but none of this make strings.h really standard. Wouldn't it again be
>> libiberty to cover for the differences (e.g. lack of ffs() decl) in such a
>> case?
>
> ffs() is declared in strings.h in both hpux11 and glibc linux.  So, I don't
> think this is a libiberty issue.
>
> I would have thought this issue would affect glibc targets.  Have you tried
> building binutils with gcc-16 or looking for a warning regarding the implicit
> declaration of ffs()?

Note that it changed in GCC 14. Not saying this to be pedantic, but that
there's been no recent change here (~1.5 years ago now, nearly 2) in
terms of GCC, and maybe something else broke instead.

>
> Maybe problem is hidden by gcc's __builtin_ffs() on targets with hardware support
> for ffs.  Maybe would show if -fno-builtin is added to CFLAGS for build.
>
> Dave
  

On 2025-12-02 2:44 a.m., Jan Beulich wrote:
> On 01.12.2025 18:12, John David Anglin wrote:
>> On 2025-12-01 11:11 a.m., Jan Beulich wrote:
>>> Okay, but none of this make strings.h really standard. Wouldn't it again be
>>> libiberty to cover for the differences (e.g. lack of ffs() decl) in such a
>>> case?
>>
>> ffs() is declared in strings.h in both hpux11 and glibc linux.  So, I don't
>> think this is a libiberty issue.
> 
> I didn't say it's a libiberty issue; I said libiberty might help addressing
> the issue. Or else other configure machinery to determine whether strings.h
> exists and actually contains what we're after. Recall that other, "less-GNU"
> environments (think about the *BSD-s, for example, or see how there's
> makefile.vms) also need to be covered (i.e. keep building).
> 
> That said, I notice bfd/elf32-xtensa.c includes strings.h unconditionally as
> well. I'd similarly question this being legitimate.

Okay.  I agree that if <strings.h> needs to be included it should be guarded.

>> I would have thought this issue would affect glibc targets.  Have you tried
>> building binutils with gcc-16 or looking for a warning regarding the implicit
>> declaration of ffs()?
> 
> What I see is configure output like this
> 
> checking whether declaration is required for ffs... yes
> 
> and later
> 
> checking whether ffs is declared... yes
> 
> No compiler warnings. Instead bfd/sysdep.h already has
> 
> #if !HAVE_DECL_FFS
> extern int ffs (int);
> #endif
> 
> So is it perhaps the case that configure doesn't work correctly on hpux?

If <strings.h> is not included in sysdep.h, we hit the following error:

../../src/bfd/elflink.c: In function 'elf_link_add_object_symbols':
../../src/bfd/elflink.c:5521:30: error: implicit declaration of function 'ffs' [
-Wimplicit-function-declaration]
 5521 |               symbol_align = ffs (h->root.u.def.value) - 1;
      |                              ^~~

We have the following in bfd/config.h:

/* Define to 1 if you have the declaration of `ffs', and to 0 if you don't. */
#define HAVE_DECL_FFS 1

So, the declaration in bfd/sysdep.h doesn't work.

It would seem autoconf 2.69 searches strings.h for ffs.  ac_includes_default
has

#ifdef HAVE_STRINGS_H
# include <strings.h>
#endif

Dave
  

On 02.12.2025 16:21, John David Anglin wrote:
> On 2025-12-02 2:44 a.m., Jan Beulich wrote:
>> On 01.12.2025 18:12, John David Anglin wrote:
>>> On 2025-12-01 11:11 a.m., Jan Beulich wrote:
>>>> Okay, but none of this make strings.h really standard. Wouldn't it again be
>>>> libiberty to cover for the differences (e.g. lack of ffs() decl) in such a
>>>> case?
>>>
>>> ffs() is declared in strings.h in both hpux11 and glibc linux.  So, I don't
>>> think this is a libiberty issue.
>>
>> I didn't say it's a libiberty issue; I said libiberty might help addressing
>> the issue. Or else other configure machinery to determine whether strings.h
>> exists and actually contains what we're after. Recall that other, "less-GNU"
>> environments (think about the *BSD-s, for example, or see how there's
>> makefile.vms) also need to be covered (i.e. keep building).
>>
>> That said, I notice bfd/elf32-xtensa.c includes strings.h unconditionally as
>> well. I'd similarly question this being legitimate.
> 
> Okay.  I agree that if <strings.h> needs to be included it should be guarded.
> 
>>> I would have thought this issue would affect glibc targets.  Have you tried
>>> building binutils with gcc-16 or looking for a warning regarding the implicit
>>> declaration of ffs()?
>>
>> What I see is configure output like this
>>
>> checking whether declaration is required for ffs... yes
>>
>> and later
>>
>> checking whether ffs is declared... yes
>>
>> No compiler warnings. Instead bfd/sysdep.h already has
>>
>> #if !HAVE_DECL_FFS
>> extern int ffs (int);
>> #endif
>>
>> So is it perhaps the case that configure doesn't work correctly on hpux?
> 
> If <strings.h> is not included in sysdep.h, we hit the following error:
> 
> ../../src/bfd/elflink.c: In function 'elf_link_add_object_symbols':
> ../../src/bfd/elflink.c:5521:30: error: implicit declaration of function 'ffs' [
> -Wimplicit-function-declaration]
>  5521 |               symbol_align = ffs (h->root.u.def.value) - 1;
>       |                              ^~~
> 
> We have the following in bfd/config.h:
> 
> /* Define to 1 if you have the declaration of `ffs', and to 0 if you don't. */
> #define HAVE_DECL_FFS 1
> 
> So, the declaration in bfd/sysdep.h doesn't work.
> 
> It would seem autoconf 2.69 searches strings.h for ffs.  ac_includes_default
> has
> 
> #ifdef HAVE_STRINGS_H
> # include <strings.h>
> #endif

And I guess your change to bfd/sysdep.h then wants to similarly have an #ifdef
around it. At the same time the questionable #include could / should then be
dropped from bfd/elf32-xtensa.c.

Jan
  

On 2025-12-03 4:15 a.m., Jan Beulich wrote:
> On 02.12.2025 16:21, John David Anglin wrote:
>> On 2025-12-02 2:44 a.m., Jan Beulich wrote:
>>> On 01.12.2025 18:12, John David Anglin wrote:
>>>> On 2025-12-01 11:11 a.m., Jan Beulich wrote:
>>>>> Okay, but none of this make strings.h really standard. Wouldn't it again be
>>>>> libiberty to cover for the differences (e.g. lack of ffs() decl) in such a
>>>>> case?
>>>>
>>>> ffs() is declared in strings.h in both hpux11 and glibc linux.  So, I don't
>>>> think this is a libiberty issue.
>>>
>>> I didn't say it's a libiberty issue; I said libiberty might help addressing
>>> the issue. Or else other configure machinery to determine whether strings.h
>>> exists and actually contains what we're after. Recall that other, "less-GNU"
>>> environments (think about the *BSD-s, for example, or see how there's
>>> makefile.vms) also need to be covered (i.e. keep building).
>>>
>>> That said, I notice bfd/elf32-xtensa.c includes strings.h unconditionally as
>>> well. I'd similarly question this being legitimate.
>>
>> Okay.  I agree that if <strings.h> needs to be included it should be guarded.
>>
>>>> I would have thought this issue would affect glibc targets.  Have you tried
>>>> building binutils with gcc-16 or looking for a warning regarding the implicit
>>>> declaration of ffs()?
>>>
>>> What I see is configure output like this
>>>
>>> checking whether declaration is required for ffs... yes
>>>
>>> and later
>>>
>>> checking whether ffs is declared... yes
>>>
>>> No compiler warnings. Instead bfd/sysdep.h already has
>>>
>>> #if !HAVE_DECL_FFS
>>> extern int ffs (int);
>>> #endif
>>>
>>> So is it perhaps the case that configure doesn't work correctly on hpux?
>>
>> If <strings.h> is not included in sysdep.h, we hit the following error:
>>
>> ../../src/bfd/elflink.c: In function 'elf_link_add_object_symbols':
>> ../../src/bfd/elflink.c:5521:30: error: implicit declaration of function 'ffs' [
>> -Wimplicit-function-declaration]
>>  5521 |               symbol_align = ffs (h->root.u.def.value) - 1;
>>       |                              ^~~
>>
>> We have the following in bfd/config.h:
>>
>> /* Define to 1 if you have the declaration of `ffs', and to 0 if you don't. */
>> #define HAVE_DECL_FFS 1
>>
>> So, the declaration in bfd/sysdep.h doesn't work.
>>
>> It would seem autoconf 2.69 searches strings.h for ffs.  ac_includes_default
>> has
>>
>> #ifdef HAVE_STRINGS_H
>> # include <strings.h>
>> #endif
> 
> And I guess your change to bfd/sysdep.h then wants to similarly have an #ifdef
> around it. At the same time the questionable #include could / should then be
> dropped from bfd/elf32-xtensa.c.

I'm testing a revised patch.

Dave