cross-build: fix bootstrap with clang 19 on glibc systems

[arichardson]

Summary

glibc defines two versions of strerror_r, the char* returning one is used
when _GNU_SOURCE is defined. This triggers a -Wint-conversion error in
the krb5 strerror_r wrapper, but until clang 19 this was just a normal
warning, now it defaults to being an error.

/home/runner/work/freebsd-src/freebsd-src/crypto/krb5/src/util/support/strerror_r.c: In function ‘k5_strerror_r’:
/home/runner/work/freebsd-src/freebsd-src/crypto/krb5/src/util/support/strerror_r.c:94:12: warning: returning ‘char *’ from a function with return type ‘int’ makes integer from pointer without a cast [-Wint-conversion]

94 |     return strerror_r(errnum, buf, buflen);
   |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This was not caught by the GitHub CI since it still builds with clang 18
on the Linux runners. Add -Werror=int-conversion to the build flags to
catch errors like this in the future.

MFC after: 3 days

[jrtc27]

krb5/include/autoconf.h

701

Don't we know how we're configuring krb5 and therefore which feature macros are being enabled? Can this not just be a __GLIBC__ check? Or even __gnu_linux__ which I think won't be set for musl and comes from the compiler itself, though Clang doesn't do the right thing there, it defines it for any Linux that's not Android, regardless of libc...

[arichardson]

krb5/include/autoconf.h

701

We add -D_GNU_SOURCE, but this header is included before any other system headers so GLIBC will not be defined without features.h.

Looking at LLVM's OSTargets.h, it seems like gnu_linux is defined for everything other than Android, so we can't use that. I felt that including features.h was the least ugly workaround but happy if there is a better way. I haven't looked into what musl does, but I imagine it matches, so maybe we can just use linux?

[arichardson]

Okay it looks like musl does not have the weird char* strerror_r: https://git.musl-libc.org/cgit/musl/tree/include/string.h#n66, so it will need to be conditional on glibc.

[jrtc27]

I forgot about this revision and ended up reinventing it in 4dd2b869cd078ed6f40c42d1ef429222da16a58f and 34e7a57673c9730ee5d1f7ebb07e152567bd8e0b so it should be fixed in-tree. I did however retain the knowledge about Clang's bugginess wrt __gnu_linux__ (and wondered where I'd got that from...) so did not use it myself... I did also check musl matched us rather than glibc.

[arichardson]

In D52526#1228266, @jrtc27 wrote:

I forgot about this revision and ended up reinventing it in 4dd2b869cd078ed6f40c42d1ef429222da16a58f and 34e7a57673c9730ee5d1f7ebb07e152567bd8e0b so it should be fixed in-tree. I did however retain the knowledge about Clang's bugginess wrt __gnu_linux__ (and wondered where I'd got that from...) so did not use it myself... I did also check musl matched us rather than glibc.

Thanks for committing this. Do we still need the && defined(__USE_GNU)? Technically it's needed but I guess this file is only every compiled with -D_GNU_SOURCE so probably doesn't matter?

[jrtc27]

In D52526#1228284, @arichardson wrote:

In D52526#1228266, @jrtc27 wrote:

I forgot about this revision and ended up reinventing it in 4dd2b869cd078ed6f40c42d1ef429222da16a58f and 34e7a57673c9730ee5d1f7ebb07e152567bd8e0b so it should be fixed in-tree. I did however retain the knowledge about Clang's bugginess wrt __gnu_linux__ (and wondered where I'd got that from...) so did not use it myself... I did also check musl matched us rather than glibc.

Thanks for committing this. Do we still need the && defined(__USE_GNU)? Technically it's needed but I guess this file is only every compiled with -D_GNU_SOURCE so probably doesn't matter?

Yeah I don't think this is the first place we assume _GNU_SOURCE is in use (and I doubt it builds without), and I'd rather not poke at internal defines if at all possible (i.e. only add it if we ever end up in a case where we get the non-GNU prototype with glibc).

[arichardson]

In D52526#1228287, @jrtc27 wrote:

In D52526#1228284, @arichardson wrote:

In D52526#1228266, @jrtc27 wrote:

I forgot about this revision and ended up reinventing it in 4dd2b869cd078ed6f40c42d1ef429222da16a58f and 34e7a57673c9730ee5d1f7ebb07e152567bd8e0b so it should be fixed in-tree. I did however retain the knowledge about Clang's bugginess wrt __gnu_linux__ (and wondered where I'd got that from...) so did not use it myself... I did also check musl matched us rather than glibc.

Thanks for committing this. Do we still need the && defined(__USE_GNU)? Technically it's needed but I guess this file is only every compiled with -D_GNU_SOURCE so probably doesn't matter?

Yeah I don't think this is the first place we assume _GNU_SOURCE is in use (and I doubt it builds without), and I'd rather not poke at internal defines if at all possible (i.e. only add it if we ever end up in a case where we get the non-GNU prototype with glibc).

sounds good thanks.