Created attachment 401222 [details] build.log tried to emerge dependencies for libreoffice and got stuck at openldap, which fails to build. I tried all versions in tree > 2.4 build.log is attached.
Created attachment 401224 [details] output of emerge --info
Can confirm that it occurs on x86 (but not amd64).
Created attachment 401260 [details, diff] Patch for openldap-2.4.38 Please test whether it also works for you. Problem is that on x86 musl size_t=unsigned int whereas ber_len_t will be unsigned long. Although they have the same size and signedness gcc views them as different.
correct, the bug occurs only on x86. with the patch it is compiling. is there any way to enable the patch only on x86 machines? for amd64, there is no need for patching.
Yes, it is possible to apply the patch only for x86, but I'm very sure that it is also necessary for all 32bit archs. (It also should not break amd64.) I'm wondering why they had to invent ber_len_t...
should I provide a patch for the overlay with keywords being restricted to x86?
Creating a patch for the overlay would be useful. But please don't special case x86. Currently, on musl size_t is unsigned int on all 32bit archs. So the patch is necessary on all 32bit archs. On 64bit archs size_t is unsigned long and so the patch does not change the behavior there.
so should I restrict KEYWORDS to arm mips ppc x86, deleting amd64 from the list?
Either of removing or keeping amd64 KEYWORD is fine.
Actually the problem is better solved by removing #Fix for glibc-2.8 and ucred. Bug 228457. append-cppflags -D_GNU_SOURCE from the ebuild. Is that fix still necessary? Explanation for the compilation failure with musl: openldap's liblber has void *ber_memcalloc(ber_len_t, ber_len_t); and in rewrite-int.h there is the definition #define calloc(x,y) ber_memcalloc(x,y) On the other hand, musl's <pthread.h> includes <sched.h> which when _GNU_SOURCE is set declares void *calloc(size_t, size_t); So when _GNU_SOURCE is set and <pthread.h> is included after rewrite-int.h we get a problem and 32bit archs because there, as described above, size_t does not match ber_len_t.
Indeed, the problem of bug 228457 has been fixed with http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/liblutil/getpeereid.c;hb=7434318a17001a3ba841de53d8472e6d155c47ad in 2009. So the hack can be removed for all openldap-2.4.*
Either removing the hack or adding the patch is helpfull, at least on i686.
(In reply to Felix Janda from comment #11) > Indeed, the problem of bug 228457 has been fixed with > > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/ > liblutil/getpeereid.c;hb=7434318a17001a3ba841de53d8472e6d155c47ad > > in 2009. So the hack can be removed for all openldap-2.4.* @ldap herd. Can we get that old hack removed?
(In reply to Anthony Basile from comment #13) > (In reply to Felix Janda from comment #11) > > Indeed, the problem of bug 228457 has been fixed with > > > > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/ > > liblutil/getpeereid.c;hb=7434318a17001a3ba841de53d8472e6d155c47ad > > > > in 2009. So the hack can be removed for all openldap-2.4.* > > @ldap herd. Can we get that old hack removed? I just looked at at this for prometheanfire. 2.4.40-r4 compiled just fine. I do think we can drop append-cppflags -D_GNU_SOURCE safely but even with it in there, it built just fine on amd64 musl. I didn't test i686, but I don't see how arch would make a difference here.
See comments 3 and 4. (tldr; amd64 has never been broken)
(In reply to Felix Janda from comment #15) > See comments 3 and 4. (tldr; amd64 has never been broken) Yep confirmed. @openldap team: can i go ahead and commit the following to 2.4.40-r5 which I'll copy from -r4 --- openldap-2.4.40-r4.ebuild.orig 2015-08-10 13:27:55.471345582 +0000 +++ openldap-2.4.40-r4.ebuild 2015-08-10 13:28:02.271345793 +0000 @@ -371,9 +371,6 @@ } src_configure() { - #Fix for glibc-2.8 and ucred. Bug 228457. - append-cppflags -D_GNU_SOURCE - # Bug 408001 use elibc_FreeBSD && append-cppflags -DMDB_DSYNC=O_SYNC -DMDB_FDATASYNC=fsync
ping!
I added 2.4.42 to the tree with the fix, given it's a new version we should probably wait for stabilization.
(In reply to Matthew Thode ( prometheanfire ) from comment #18) > I added 2.4.42 to the tree with the fix, given it's a new version we should > probably wait for stabilization. it works. since this was a gentoo only problem, i'm closing this bug. nothing to go upstream. Let's aim to stabilize 2.4.42.
