Bugzilla – Bug 1214232
[FTBFS] crash/crash-trace fail to build against glibc 2.38
Last modified: 2023-12-08 14:49:17 UTC
glibc 2.38 has been introduced to Factory recently. crash and crash-trace are among the few packages that fail to build with this update. Both fail very similar: [ 5s] /usr/include/crash/defs.h:5517:8: error: conflicting types for 'strlcpy'; have 'size_t(char *, char *, size_t)' {aka 'long unsigned int(char *, char *, long unsigned int)'} [ 5s] 5517 | size_t strlcpy(char *, char *, size_t); [ 5s] | ^~~~~~~ [ 5s] In file included from /usr/include/features.h:503, [ 5s] from /usr/include/bits/libc-header-start.h:33, [ 5s] from /usr/include/stdio.h:27, [ 5s] from /usr/include/crash/defs.h:22: [ 5s] /usr/include/bits/string_fortified.h:150:1: note: previous definition of 'strlcpy' with type 'size_t(char * restrict, const char * restrict, size_t)' {aka 'long unsigned int(char * restrict, const char * restrict, long unsigned int)'} [ 5s] 150 | __NTH (strlcpy (char *__restrict __dest, const char *__restrict __src, [ 5s] | ^~~~~
crash has it's own definition (therefore declaration) of strlcpy that aqppears to conflict with the one in glibc 2.38. The glibc one isn't needed if crash uses it's own definition so it looks like the overlap of using the internal definition AND the use of glibc header including a different declaration for the same function is the cause. From here I'm trying to make the definitions overlap. It may have to be target product specific.
It looks like size_t is long unsigned int which is not __NTH. Changing the crash definition of the return type of the crash version of strlcpy() to match the glibc 2.38 version. It's better than migrating from the internal functions in crash to actually using the glibc version because making them match doesn't require a quite major change in crash upstream.
(In reply to David Mair from comment #2) > It looks like size_t is long unsigned int which is not __NTH... For anyone that doesn't recognize it the meaning is no throw, not nTh (i.e. some index/length identity). No throw should be automatic in C code, which implies the internal function in crash isn't declared no throw but the matching glibc version is. It should be safe to make that declaration without damage. Working on it.
This problem is from a combination of gcc and glibc versions rather than just glibc (the failure points at glibc alone but it isn't really just there). __NTH is a macro for "attribute ((nothrow))" which is used in a function declaration/definition as an indication to gcc that the function can't (won't) throw exceptions. So far, I can't make __NTH in-scope when handling crash's defs.h (though I've barely started) and expanding __NTH by hand to the use of gcc's __attribute__ ((__nothrow__)) for the crash version of strlcpy() isn't immediately a solution. I only dealt with the declaration without looking for a crash definition yet. Unfortunately, it does look like some places in crash get the declaration of strlcpy() from the internal declaration (crash header), some from glibc headers. It might be a bit messy to clean up from that.
It appears that recent gcc version error point underlining (^~~~~~~) isn't quite accurate. It underlines strlcpy from crash and __NTH from glibc. I've seen the different argument types since the start but assumes the line under the __NTH was what mattered. But it's really the function argument types, the glibc declaration before crash declaration: size_t __NTH strlcpy(char *, const char *, size_t); size_t strlcpy(char *, char *, size_t); The constness of the second argument (source string to copy from) is the problem, making those the same by making the crash function have a const char *src resolves it in my local build. I'll submit changes within the hour.
It's submitted and accepted, I'll let the bug stay open while watching for it's incorporation.
(In reply to David Mair from comment #6) > It's submitted and accepted, I'll let the bug stay open while watching for > it's incorporation. => seems to have all gone right. Closing