Emerging of wine-1.1.13 on AMD64 and the "ldap" USE flag enabled fails with: "configure: error: libldap (OpenLDAP) 32-bit development files not found, LDAP won't be supported." I already have wine-1.1.13 installed with ldap enabled, but portage wanted to reinstall since the ebuild got changed and some new USE flags were introduced. Whatever the changes were, they broke ldap on AMD64. Reproducible: Always Steps to Reproduce: 1. Make sure the "ldap" USE flag for app-emulation/wine is enabled 2. emerge =app-emulation/wine-1.1.13 Actual Results: checking for LDAPSortKey... yes checking for ldap_initialize in -lldap_r... no checking for ldap_count_references... no checking for ldap_first_reference... no checking for ldap_next_reference... no checking for ldap_parse_reference... no checking for ldap_parse_sort_control... no checking for ldap_parse_sortresponse_control... no checking for ldap_parse_vlv_control... no checking for ldap_parse_vlvresponse_control... no configure: error: libldap (OpenLDAP) 32-bit development files not found, LDAP won't be supported. This is an error since --with-ldap was requested. !!! Please attach the following file when seeking support: !!! /var/tmp/portage/app-emulation/wine-1.1.13/work/wine-1.1.13/config.log * * ERROR: app-emulation/wine-1.1.13 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 172: Called econf '--sysconfdir=/etc/wine' '--without-alsa' '--with-cups' '--with-esd' '--without-gnutls' '--without-hal' '--without-jack' '--with-jpeg' '--without-cms' '--with-ldap' '--without-nas' '--with-curses' '--with-opengl' '--with-oss' '--with-png' '--without-scanner' '--with-openssl' '--without-win64' '--with-x' '--without-xcomposite' '--without-xinerama' '--with-xml' '--with-xslt' * ebuild.sh, line 543: Called die * The specific snippet of code: * die "econf failed" * The die message: * econf failed Expected Results: Successful emerge. I tried with net-nds/openldap-2.3.43 (amd64) as well as with 2.3.43-r1 (~amd64). I emerged openldap and wine again without the "--as-needed" linker flag in case it had something to do with it but Wine still failed. I am attaching my "emerge --info".
Created attachment 178969 [details] emerge --info
Created attachment 178970 [details] config.log
I checked previous versions of the wine ebuilds and it seems that --with-ldap was NOT enabled even though the "ldap" USE flag was actually enabled. It looks like a bug that got fixed with the latest 1.1.13 ebuild. The vanilla tarballs of wine (1.1.12 and 1.1.13) also fail with the same error message if using --with-ldap, so it seems this is not a Gentoo-specific issue?
*** Bug 255506 has been marked as a duplicate of this bug. ***
Note that the error logs point to 32-bit openldap libraries having the problems, so jiggling the 64-bit libraries will probably not help. For an unknown reason the linker cannot connect the dots between 32-bit libldap_r and 32-bit libpthread, which would have, e.g., the phtread_kill_other_threads_np. This can be temporarily worked around in compilation by giving the -Wl,--allow-shlib-undefined, but that would probably just move the problem to runtime and even bigger error-fireworks or more obscure tracedumps. 32-bitness would make emul-linux-x86-baselibs the likely trouble source since it provides the 32-bit openldap binaries. I tried both 2008 versions of emul baselibs, but got same results. The undefined reference to *threads_np that Mr Malley and I got with glibc 2.7 and 2.8 respectively, could of course indicate some relation to glibc. Mr Chantziaras uses an even newer glibc (2.9) and gets seven more undefined references along the one we get -- so possibly something to do with glibc API/ABI cleanup? I tried to recompile glibc as well, but no luck there either. Still, all years old documentation I can find indicates that software calling *threads_np should be fixed. So is it back to emul baselibs and we'd just need a new one? One which is compiled on a system with nptl enabled (to suppress using these old tricks and gnu-specific "hacks" like *threads_np)? Anyone wanting to try to build 32-bit emul libs with nptl enabled and see if it fixes this? I'm too busy to learn it right now, but maybe during the weekend I may find some time. :)
This is caused because of have dropped: multilib_toolchain_setup x86 I am unsure about this needed also when "win64" is set, but in both cases wine seems to ebuild if I apply the following diff to the ebuild: --- wine-1.1.13.ebuild~ 2009-01-20 21:02:54.000000000 +0100 +++ wine-1.1.13.ebuild 2009-01-20 21:02:54.000000000 +0100 @@ -86,6 +86,8 @@ src_compile() { export LDCONFIG=/bin/true + use amd64 && multilib_toolchain_setup x86 + # XXX: should check out these flags too: # audioio capi fontconfig freetype gphoto econf \
It still fails :-S, sorry (how many times is configure run?)
*** Bug 255569 has been marked as a duplicate of this bug. ***
app-emulation/emul-linux-x86-baselibs installs a broken 32 ldap binary. if ldap_r uses pthreads, it needs to link against it. configure:18920: checking for ldap_initialize in -lldap_r configure:18955: x86_64-pc-linux-gnu-gcc -m32 -o conftest -march=core2 -O2 -fomit-frame-pointer -pipe -Wl,-O1,--hash-style=gnu,--sort-common,--as-needed conftest.c -lldap_r -lpthread >&5 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/libldap_r.so: undefined reference to `pthread_mutex_trylock' /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/libldap_r.so: undefined reference to `pthread_getconcurrency'
billydv1@verizon.net
*** Bug 255950 has been marked as a duplicate of this bug. ***
*** Bug 256105 has been marked as a duplicate of this bug. ***
Confirmed fixed on my setup as of this evening (PST). Can anyone else who's affected confirm?
(In reply to comment #13) > Confirmed fixed on my setup as of this evening (PST). > Can anyone else who's affected confirm? I can't enable the ldap USE flag at all now. So I guess it's FIXED this way.
