Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 546556 - net-nds/openldap-2.4.38-r2 fails to build with musl
Summary: net-nds/openldap-2.4.38-r2 fails to build with musl
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: LDAP Herd
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: musl-porting 546890
  Show dependency tree
 
Reported: 2015-04-14 11:09 UTC by tt_1
Modified: 2015-09-04 00:58 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (openldap-2.4.38-r2-build.log,243.41 KB, text/plain)
2015-04-14 11:09 UTC, tt_1
Details
output of emerge --info (emerge.info.log,4.29 KB, text/plain)
2015-04-14 11:11 UTC, tt_1
Details
Patch for openldap-2.4.38 (openldap.patch,455 bytes, patch)
2015-04-14 18:03 UTC, Felix Janda
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.