Trying to update my system (96 packages to go) and the build of openldap does not get past the ./configure stage. See the URL. Mark Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.49_pre18 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1, 2.4.20-gentoo-r5) ================================================================= System uname: 2.4.20-gentoo-r5 i686 Pentium II (Deschutes) GENTOO_MIRRORS="http://adelie.polymtl.ca/ ftp://cs.ubishops.ca/pub/gentoo ftp://sunsite.ualberta.ca/pub/unix/Linux/gentoo/ http://www.ibiblio.org/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /opt/tomcat/conf /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 oss apm avi crypt cups encode foomaticdb gif jpeg gnome libg++ mad mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib directfb gtkhtml alsa gdbm berkdb slang readline arts tetex aalib nas bonobo svga ggi tcltk java guile ruby mysql postgres X sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis gtk qt kde motif opengl gphoto2 cdr scanner acl apache2 athena cscope curl dga dvd fbcon gb gd imap innodb ipv6 jikes junit kerberos ldap libgda maildir mbox mcal pda plotutils ppds samba sasl slp snmp socks5 sse tiff usagi usb vim-with-x wmf Xaw3d xinerama -3dnow" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium2 -O2 -pipe" CXXFLAGS="-march=pentium2 -O2 -pipe" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j3" AUTOCLEAN="yes" SYNC="rsync://rsync.ca.gentoo.org/gentoo-portage" FEATURES="sandbox ccache distcc"
Look's like emerging with USE="-berkdb" is a workaround. I am emerging it now and it is actually compiling. Does not solve the problem but it lets me carry on with my updates. Mark
*** Bug 27407 has been marked as a duplicate of this bug. ***
If the reporter is using db-3.2.9-r8 then it's likely that a missing libdb-3.so is the cause of this bug (see Bug #27708). If so then db-3.2.9-r9 fixes this nicely. :)
That's probably right. I have berkdb 4.x installed right now. Probably openldap requires 3.x That being said, portage keeps flip-flopping my version of berkdb. 4.x is installed right now, but portage wants to "upgrade" to 3.x. Whenever I let it "upgrade", my next `emerge -u world` wants to "upgrade" me back to 4.x. But that's a separate issue. Mark
Once I get DB 3.x reinstalled I'll re-emerge openldap and report back here. Mark
Actually db3 and db4 are slotted and should work in parallel, both need to have upgraded versions, and upgrading both should be expected. If installation of db4 does automatically unmerge db3 then it is a bug that should be reported.
I take it slots are not represented in the emerge -p output? My latest emerge -upDv world look's like this: nbCS566 root # emerge -upDv world These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild U ] sys-libs/db-3.2.9-r9 [4.0.14-r2] -doc . . . So this only *look's* like 4.x is being upgraded to 3.x? Mark
That's fixed it: tess root # qpkg -I -i db sys-libs/db-1.85-r1 * db 1.85 -- required for RPM 4.0 to compile; that's about it. [ http://www.sleepycat.com ] sys-libs/db-3.2.9-r9 * Berkeley DB for transaction support in MySQL [ http://www.sleepycat.com/ ] sys-libs/db-4.0.14-r2 * Berkeley DB [ http://www.sleepycat.com ] tess root # qpkg -I -i openldap net-nds/openldap-2.0.27-r4 * LDAP suite of application and development tools [ http://www.OpenLDAP.org/ ] tess root #
its still a bug here. what did you do to get openldap to build on your system?
my system is smoking crack. re-closing :-/
I recommend you to reopen this bug immediately or tell me how to actually emerge OpenLDAP v2.1.x. :-) Just tried to emerge openldap-2.1.23 with BerkeleyDB support. That did fail to "Error: BerkeleyDB is not available" error during the openldap ./configuration phase. I thought that maybe that's just a glitch with openldap-2.1.23 ebuild and 2.1.22 would work but no, it did not. I'll try to find what's causing this. I currently have db-1.85-r1, db-3.2.9-r9, db-4.0.14-r2 and db-4.1.25_p1-r3 installed, so one would think that some of those could satisfy OpenLDAP's BDB needs. But no go. I'm not using ACCEPT_KEYWORDS="~x86", except for OpenLDAP installation. I very much would like to use BDB backend -- isn't that the recommended backend type anyway?
Even openldap-2.0.x seems to be unable to find Berkeley DB libraries during the ./configure. Something is badly b0rked in OpenLDAP or in DB ebuilds...
And to be more specific: OpenLDAP 2.0.x configure doesn't die to missing BDB link and it continues & compiles, but it simply doesn't find any BDB links during the configure.
openldap-2.1.23 did compile nicely with BDB backend support after I manually emerged db-4.0.14. With db-4.0.14-r2 it did not work. Maybe that gives us a clue what's wrong.
