Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 546556

Summary: net-nds/openldap-2.4.38-r2 fails to build with musl
Product: Gentoo Linux Reporter: tt_1 <herrtimson>
Component: [OLD] UnspecifiedAssignee: LDAP Herd <ldap-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: blueness
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 430702, 546890    
Attachments: build.log
output of emerge --info
Patch for openldap-2.4.38

Description tt_1 2015-04-14 11:09:32 UTC
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.
Comment 1 tt_1 2015-04-14 11:11:34 UTC
Created attachment 401224 [details]
output of emerge --info
Comment 2 Felix Janda 2015-04-14 18:00:51 UTC
Can confirm that it occurs on x86 (but not amd64).
Comment 3 Felix Janda 2015-04-14 18:03:41 UTC
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.
Comment 4 tt_1 2015-04-14 19:50:11 UTC
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.
Comment 5 Felix Janda 2015-04-16 19:46:49 UTC
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...
Comment 6 tt_1 2015-04-17 08:24:53 UTC
should I provide a patch for the overlay with keywords being restricted to x86?
Comment 7 Felix Janda 2015-04-17 18:43:51 UTC
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.
Comment 8 tt_1 2015-04-22 07:30:14 UTC
so should I restrict KEYWORDS to arm mips ppc x86, deleting amd64 from the list?
Comment 9 Felix Janda 2015-04-22 19:17:10 UTC
Either of removing or keeping amd64 KEYWORD is fine.
Comment 10 Felix Janda 2015-04-25 13:24:30 UTC
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.
Comment 11 Felix Janda 2015-04-25 14:02:40 UTC
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.*
Comment 12 tt_1 2015-04-27 18:15:07 UTC
Either removing the hack or adding the patch is helpfull, at least on i686.
Comment 13 Anthony Basile gentoo-dev 2015-05-13 17:55:59 UTC
(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?
Comment 14 Anthony Basile gentoo-dev 2015-08-08 02:35:55 UTC
(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.
Comment 15 Felix Janda 2015-08-08 14:24:21 UTC
See comments 3 and 4. (tldr; amd64 has never been broken)
Comment 16 Anthony Basile gentoo-dev 2015-08-10 13:37:34 UTC
(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
Comment 17 Anthony Basile gentoo-dev 2015-08-27 11:16:58 UTC
ping!
Comment 18 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2015-09-03 19:37:26 UTC
I added 2.4.42 to the tree with the fix, given it's a new version we should probably wait for stabilization.
Comment 19 Anthony Basile gentoo-dev 2015-09-04 00:58:55 UTC
(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.