Bug#1008951: openldap FTBFS on musl-linux-any: conflicting declaration of calloc
Control: forwarded -1 https://bugs.openldap.org/show_bug.cgi?id=9841 Control: tags - moreinfo Hi Ryan, On Wed, May 04, 2022 at 05:47:12PM -0700, Ryan Tandy wrote: > Has this been reported upstream yet? I searched and didn't find this > specific issue, but it looks like upstream have fixed at least two other > musl-specific issues recently [ITS#9648, ITS#9650]. Both are unrelated to the issue I reported. > Before applying a patch for this in Debian, I'd at least like to know > whether and how upstream intend to address the issue. I'd rather not take a > patch if it has no future upstream. The more I see about this issue, the more I am convinced that this is actually two bugs, not just one. 1. musl should not declare a calloc in . Beyond breaking openldap, this also causes issues with libgccjit[citation needed]. 2. openldap should not #define calloc before #including system headers. Fixing either of these fixes the issue I reported. At this point, I recommend fixing both. I've just created a matching report at https://bugs.openldap.org/show_bug.cgi?id=9841. Hope this works out. Helmut
Bug#1008951: openldap FTBFS on musl-linux-any: conflicting declaration of calloc
Control: tag -1 upstream moreinfo Hi Helmut, Thanks for the analysis and patch, and sorry for the slow response. Has this been reported upstream yet? I searched and didn't find this specific issue, but it looks like upstream have fixed at least two other musl-specific issues recently [ITS#9648, ITS#9650]. Before applying a patch for this in Debian, I'd at least like to know whether and how upstream intend to address the issue. I'd rather not take a patch if it has no future upstream. thanks, Ryan [ITS#9648]: https://bugs.openldap.org/show_bug.cgi?id=9648 [ITS#9650]: https://bugs.openldap.org/show_bug.cgi?id=9650
Bug#1008951: openldap FTBFS on musl-linux-any: conflicting declaration of calloc
Control: tags -1 + patch On Mon, Apr 04, 2022 at 09:54:13PM +0200, Helmut Grohne wrote: > The gentoo bug has a few more details and proposed two distinct > workarounds: > a. Drop the _GNU_SOURCE define. Doing so makes musl's sched.h not emit > a calloc declaration. I don't know what other consequences this > would have. > b. Change LBER_LEN_T to size_t. I suppose doing so would break ABI on > 64bit architectures. Proposing a third one that practically works and has little risk of breakage: c. Reorder the #define calloc vs #include This doesn't fix the root cause, but the symptom. :) Helmut --- a/libraries/librewrite/rewrite-int.h +++ b/libraries/librewrite/rewrite-int.h @@ -40,6 +40,11 @@ #include +#ifndef NO_THREADS +#define USE_REWRITE_LDAP_PVT_THREADS +#include +#endif + #define malloc(x) ber_memalloc(x) #define calloc(x,y) ber_memcalloc(x,y) #define realloc(x,y) ber_memrealloc(x,y) @@ -47,11 +52,6 @@ #undef strdup #define strdup(x) ber_strdup(x) -#ifndef NO_THREADS -#define USE_REWRITE_LDAP_PVT_THREADS -#include -#endif - /* * For details, see RATIONALE. */
Bug#1008951: openldap FTBFS on musl-linux-any: conflicting declaration of calloc
Source: openldap,musl Tags: upstream User: helm...@debian.org Usertags: rebootstrap Hi, openldap fails to build from source on musl-linux-any. The issue is not Debian-specific and has been reported for gentoo already (https://bugs.gentoo.org/546556). The visible issue is this: | In file included from ../../../../libraries/librewrite/context.c:22: | ../../../../libraries/librewrite/rewrite-int.h:44:25: error: conflicting types for ‘ber_memcalloc’; have ‘void *(size_t, size_t)’ {aka ‘void *(unsigned int, unsigned int)’} | 44 | #define calloc(x,y) ber_memcalloc(x,y) | | ^ | In file included from ../../../../libraries/librewrite/rewrite-int.h:34: | ../../../../include/lber.h:608:1: note: previous declaration of ‘ber_memcalloc’ with type ‘void *(ber_len_t, ber_len_t)’ {aka ‘void *(long unsigned int, long unsigned int)’} | 608 | ber_memcalloc LDAP_P(( | | ^ The gentoo bug explains this quite well. LBER_LEN_T is statically defined as "long" in configure.ac. Then include/lber_types.h uses that: | typedef unsigned LBER_LEN_T ber_len_t; And then, it declares ber_memcalloc using ber_len_t in include/lber.h. Finally, it #defines calloc (as be seen above) to point to ber_memcalloc. That #define lives in libraries/librewrite/rewrite-int.h, which happens to be #included before some musl header that happens to pull the definition of calloc. Thus musl's declaration is renamed to ber_memcalloc and since it uses size_t, which happens to be defined as unsigned int rather than unsigned long, we get a conflicting declaration. Looking deeper things get a little surprising. rewrite-int.h is careful to #include early. Presumably, it wants to avoid such conflicting declarations. Indeed, that's not the place the conflicting ber_memcalloc declaration originates. After the #define calloc, there is an #include , which happens to indirectly #include , which happens to #include , which happens to declare calloc, which was defined as ber_memcalloc earlier. This is sounds doubly wrong. Why would openldap re#define calloc and then #include system headers? That's risky and it makes the build fail. Why would musl declare calloc in a header different from stdlib.h? I understand neither and fixing either fixes the build. The gentoo bug has a few more details and proposed two distinct workarounds: a. Drop the _GNU_SOURCE define. Doing so makes musl's sched.h not emit a calloc declaration. I don't know what other consequences this would have. b. Change LBER_LEN_T to size_t. I suppose doing so would break ABI on 64bit architectures. Any clue how we can move forward here? Helmut