Emerging Apache2 when sasl USE flag is specified and later on, do 'emerge depclean' without sasl USE flag, this will cause the package cyrus-sasl to get removed, then doing world update causes any packages which had sasl USE flag to be updated with 'emerge -uDN world' but since Apache2 never has sasl USE flag, it will not be treated as part of the update process and causes apache2 executable not to run anymore, with libsasl.so missing errors. Reproducible: Always Steps to Reproduce: 1. Add sasl USE flag. 2. Emerge apache 3. Remove sasl USE flag. 4. Do 'emerge depclean' to clean any package that depended on sasl. 5. Update packages via 'emerge -uDN world' (which doesn't update Apache) 6. run 'apache2' Actual Results: apache2 executables causes missing library errors and will not run anymore. Expected Results: In the fifth step of the above procedure, the Apache should also be updated to reflect its own use of sasl USE flag and in sixth step, should run properly again. I just run 'ldd `which apache2`' to verify but, it was trying to use libsasl without having sasl on its ebuild for the USE flag. Thus causing this problem.
I have manually run 'emerge apache' when sasl USE flag is off and it started working again not depending on sasl library anymore.
cyrus-sasl is needed for openldap w/ sasl in USE, which is IMHO the "issue" here, but since you neglected to post emerge --info output, I can only guess.
Here's the 'emerge info' Yes I do have ldap USE flag as well, but the problem as I noted lies on apache using the sasl USE flag in make.conf to compile sasl library support while apache itself does not have such USE flag for its own ebuild, thus the confusion. Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r1, 2.6.12-gentoo-r10 i686) ================================================================= System uname: 2.6.12-gentoo-r10 i686 Transmeta Efficeon(tm) Processor TM8000 Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X 11/xkb /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.gentoo.gr.jp http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://mirror.gentoo.gr.jp/gentoo-portage" USE="x86 X alsa anthy apache2 apm berkdb cjk cli crypt cups curl dba exif firefox flac foomaticdb fortran gd gdbm gnome gtk2 imap imlib jpeg kerberos ldap libg++ libwww mmx motif mozsvg mppe-mppc mysql ncurses nls opengl pam pcntl pcre perl png python readline samba sdl sqlite sse ssl svg tcltk tcpd truetype truetype-fonts type1-fonts unicode usb userlocales xml2 xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY
(In reply to comment #3) > Yes I do have ldap USE flag as well, but the problem as I noted lies on apache > using the sasl USE flag in make.conf to compile sasl library support while > apache itself does not have such USE flag for its own ebuild, thus the > confusion. No, apache does not depend on cyrus-sasl at all, it depends on openldap w/ USE=ldap. So there's no place and need for sasl use flag. Regardless, this bug is invalid, you should use revdep-rebuild to fix issues caused by unmerging a library, not 'emerge --newuse -uD world'
Ok. openldap does recompile taking sasl USE flag when doing world upgrades, but as I noted above, apache2 executable had 'libsasl.so' as part of its dependency stated by 'ldd' command. This apache executable was compiled while having sasl USE flag, and since then I have changed nothing but sasl USE flag to go off, then done the depclean command and it safely removed cyrus-sasl. Then I did the 'emerge -uDN world' which compiled openldap and couple other packages like php to take care of the lost sasl library, but for apache until I manually emerged it again, it was by its own executable relied on libsasl. So, I think this bug is still valid, if you follow the steps which isn't anything different than any user could do in normal circumstances, the apache will stop working.
I looked at it a bit more, but neither the apache2 ebuild nor the apache source itself as in './configure --help' option has anything to do with sasl. I kept recompiling apache with and without sasl USE flag, but it seems to start working. I look a bit more in detail tomorrow having cyrus-sasl makes any difference or not.
Ok, now I reproduced the problem. Since taking away sasl USE flag and doing 'emerge depclean' then 'emerge -uDN world', my apache broke and then manually emerging apache fixed it. But, after putting sasl USE flag back on and recompiling apache, the problem does not get triggered. I have once again updated the world according to sasl USE flag on (which made it to compile php and openldap) and once again compiling apache manually with emerge, now apache2 executable according to 'ldd `which apache2`' now presents this list below. So, what I think, in a way apache does get compiled against sasl library, yet it never has USE flag (maybe because apache doesn't have such configure option or something), thus once sasl USE flag is taken down, then current apache makes error complaing about missing libsasl library. I'm not onto definitive conclusion as to what made apache go against libsasl, but it's quite possible that having cyrus-sasl as well as php and openldap compiled against sasl USE flag makes apache2 executable on its own has libsasl dependency for its executable. linux-gate.so.1 => (0xffffe000) libz.so.1 => /lib/libz.so.1 (0xb7fa9000) libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0xb7f93000) libldap-2.2.so.7 => /usr/lib/libldap-2.2.so.7 (0xb7f61000) -> libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb7f4c000) libresolv.so.2 => /lib/libresolv.so.2 (0xb7f38000) libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0xb7f07000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0xb7e05000) liblber-2.2.so.7 => /usr/lib/liblber-2.2.so.7 (0xb7df8000) libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0xb7df2000) libdb-4.2.so => /usr/lib/libdb-4.2.so (0xb7d17000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb7cf7000) libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0xb7cd7000) librt.so.1 => /lib/librt.so.1 (0xb7cc2000) libm.so.6 => /lib/libm.so.6 (0xb7c9f000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7c71000) libnsl.so.1 => /lib/libnsl.so.1 (0xb7c5c000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7c0a000) libdl.so.2 => /lib/libdl.so.2 (0xb7c06000) libc.so.6 => /lib/libc.so.6 (0xb7aed000) /lib/ld-linux.so.2 (0xb7fc6000)
apache is linked against apr-util which is linked against ldap (if you compile apr-util with the ldap USE-flag on) which is linked against sasl. There is not problem with apache here.
I had to recompile apache manually to fix though, even after recompiling openldap when sasl USE flag went off. I'm not pro at libraries and such, so I can't understand what's going on any further but yet this looks to be a bug and is reproducible with the steps mentioned in the bug report.
