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
