Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
This broke a number of dependencies. I'm hoping that a revdep-rebuild will clean things up, but is there a better way around this, or a more appropriate workaround than just making a symlink between these libraries? broken /usr/lib/perl5/5.8.1/i686-linux/auto/NDBM_File/NDBM_File.so (requires libgdbm.so.2) broken /usr/lib/perl5/5.8.1/i686-linux/auto/GDBM_File/GDBM_File.so (requires libgdbm.so.2) broken /usr/lib/rlm_counter-0.9.0.so (requires libgdbm.so.2) broken /usr/lib/python2.2/lib-dynload/gdbm.so (requires libgdbm.so.2) broken /usr/lib/rlm_ippool-0.9.0.so (requires libgdbm.so.2) broken /usr/bin/mailbot (requires libgdbm.so.2) broken /usr/bin/maildrop (requires libgdbm.so.2) broken /usr/bin/makedatprog (requires libgdbm.so.2) broken /usr/sbin/ab2 (requires libgdbm.so.2) broken /usr/sbin/htdbm (requires libgdbm.so.2) broken /usr/sbin/logresolve2 (requires libgdbm.so.2) broken /usr/sbin/htpasswd2 (requires libgdbm.so.2) broken /usr/sbin/ab2-ssl (requires libgdbm.so.2) broken /usr/sbin/rotatelogs2 (requires libgdbm.so.2) broken /usr/sbin/checkgid2 (requires libgdbm.so.2) broken /usr/sbin/htdigest2 (requires libgdbm.so.2) broken /usr/sbin/apache2 (requires libgdbm.so.2)
The symlink might work -- I can have the ebuild put one in there, but this needs to be explored. For now, I've masked this. Azarah?
SLOT 1.8.3 differently, and then leave 1.8.0 to die (meaning do not add revisions/whatever again).
And here I've almost finished recompiling openoffice on a number of boxes as it was one of the 'little' packages that depended on the so.2 file... (quite possibly opening big can of worms here:) When an old library gets slotted into history like that, will future rebuilds of python, perl, apache2, etc. be built against the newer library? And is there a way to check/encourage/force migration to the newer version and the ultimate removal of the old one? Whether the upgrade is being driven by compatibility, security, features, or whatever - I would certainly like to keep my system only using the most current versions. Unmerging the older-slotted version and running revdep-rebuild is one way to do that, but its certainly not too graceful.
Yes, it should link to the new one, as long as the older ebuild is never merged again (and overwrite libtool linker scripts, etc).
Created an attachment (id=20568) [edit] patch to apply to perl-5.8.2 for it to work with gdbm-1.8.3 Even after running revdep-rebuild, and getting everything to appear to be fine, no matter how many times I rebuilt perl, it gave me the following error during the build of perl, as well as killing programs I tried to use that depended on perl (spamassassin's spamd for example). # Failed at run/fresh_perl.t line 53 ./perl: relocation error: ../lib/auto/NDBM_File/NDBM_File.so: undefined symbol: dbm_open ./perl: relocation error: ../lib/auto/NDBM_File/NDBM_File.so: undefined symbol: dbm_open The dbm_open function is no longer in libgdbm.so, its now in libgdbm_compat.so This patch should be applied in perl-5.8.2 (maybe 5.8.1 as well?) when >=sys-libs/gdbm-1.8.3 and as revdep-rebuild after the gdbm upgrade should trigger perl to be rebuilt after gdbm goes from 1.8.0 to 1.8.3, it should take care of itself. Any packages that actually use the old ndbm (sys-libs/db-1.85) may well need the same action taken.
ok... got a tad overzealous on finding something very specific to patch. After putting a little more thought into it, and doing some better regression testing, it seems that just adding "-Di_gdbm_compat" to dev-lang/perl and sys-libs/libperl [applied here with -5.8.2 of both] does the trick nicely. if [ "`use gdbm`" ] then - myconf="${myconf} -Di_gdbm" + myconf="${myconf} -Di_gdbm -Di_gdbm_compat" fi libgdbm_compat.so doesn't exist til 1.8.3, so that logic should be taken into account in the ebuild. I did initially have troubles with memory allocation errors running the qmail-scanner with 1.8.3. However, after rebuilding libperl, perl and DB-File, things are running great.
This has shown up in perl.org's RT as far back as november, fix and all, but its still open. Can someone light a fire upstream about this? http://bugs6.perl.org/rt3/Ticket/Display.html?id=24444
Created an attachment (id=29244) [edit] add -lgdbm_compat to the makefile And call it with this: --- perl-5.8.3.ebuild 2004-03-02 09:43:58.000000000 -0700 +++ perl-5.8.3-r1.ebuild 2004-01-21 14:56:15.000000000 -0700 @@ -100,6 +100,8 @@ # counterproductive on a Gentoo system which has both a shared # and static libperl, so effectively revert this here. cd ${S}; epatch ${FILESDIR}/${P}-picdl.patch + epatch ${FILESDIR}/${P}-gdbm.patch + }
*** Bug 48587 has been marked as a duplicate of this bug. ***
Any updates on this. This is really starting to bite into apache big time.
cleaned up ebuild and added backwards support like openssl does
I just emerged gdbm-1.8.3 this morning and the ebuild doesn't appear to working as intended. I've noted two things 1. The ebuild has the following to support this bug # temp backwards support #32510 if [ -e ${ROOT}/usr/lib/libgdbm.so.2 ] ; then cp -a ${ROOT}/usr/lib/libgdbm.so.2 ${D}/usr/lib/ fi Looking at the emerge process, I see: >>> /usr/lib/libgdbm.so.2 -> libgdbm.so.2.0.0 However, Portage then uninstalls gdbm-1.8.0-r5 which shows: <<< obj /usr/lib/libgdbm.so.2.0.0 --- !mtime obj /usr/lib/libgdbm.la --- !mtime obj /usr/lib/libgdbm.a --- !mtime obj /usr/include/gdbm/ndbm.h --- !mtime obj /usr/include/gdbm/dbm.h --- !mtime obj /usr/include/gdbm.h <<< sym /usr/lib/libgdbm.so.2 So libgdbm.so.2 is removed. 2. The ebuild states: * Please run revdep-rebuild --soname libgdbm.so * Packages compiled against the previous version will not work Running that command doesn't work properly, here is the revdep-rebuild output: garath root # revdep-rebuild --soname libgdbm.so --pretend Checking reverse dependencies... Packages containing binaries and libraries using given shared object name, will be recompiled. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Checking dynamic linking... done. (/root/.revdep-rebuild_246aa0ec.3_rebuild) Assigning files to ebuilds... Nothing to rebuild Evaluating package order... done. (/root/.revdep-rebuild_246aa0ec.5_order) There are no dynamic links to libgdbm.so... All done. garath root # revdep-rebuild --pretend Checking reverse dependencies... Packages containing binaries and libraries broken by any package update, will be recompiled. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath) Checking dynamic linking consistency... broken /usr/bin/checkgid (requires libgdbm.so.2) broken /usr/bin/htdigest (requires libgdbm.so.2) broken /usr/bin/htpasswd (requires libgdbm.so.2) broken /usr/bin/openjade (requires libosp.so.3) broken /usr/bin/php (requires libgdbm.so.2) broken /usr/lib/apache-extramodules/libphp4.so (requires libgdbm.so.2) broken /usr/lib/apache/libphp4.so (requires libgdbm.so.2) broken /usr/lib/perl5/5.8.4/i686-linux/auto/GDBM_File/GDBM_File.so (requires libgdbm.so.2) broken /usr/lib/perl5/5.8.4/i686-linux/auto/NDBM_File/NDBM_File.so (requires libgdbm.so.2) broken /usr/lib/python2.3/lib-dynload/gdbm.so (requires libgdbm.so.2) broken /usr/lib/sasl2/libsasldb.so.2.0.19 (requires libgdbm.so.2) broken /usr/sbin/ab (requires libgdbm.so.2) broken /usr/sbin/apache (requires libgdbm.so.2) broken /usr/sbin/logresolve (requires libgdbm.so.2) broken /usr/sbin/rotatelogs (requires libgdbm.so.2) broken /usr/sbin/sasldblistusers2 (requires libgdbm.so.2) broken /usr/sbin/saslpasswd2 (requires libgdbm.so.2) broken /usr/sbin/suexec (requires libgdbm.so.2) done. (/root/.revdep-rebuild.3_rebuild) Assigning files to ebuilds... done. (/root/.revdep-rebuild.4_ebuilds) Evaluating package order... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild... emerge --oneshot --nodeps --pretend =dev-lang/python-2.3.4 =dev-lang/perl-5.8.4 =app-text/openjade-1.3.2-r1 =dev-libs/cyrus-sasl-2.1.19 =net-www/apache-1.3.31-r2 =dev-php/mod_php-4.3.8 =dev-php/php-4.3.8 These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] dev-lang/python-2.3.4 [ebuild R ] dev-lang/perl-5.8.4 [ebuild R ] app-text/openjade-1.3.2-r1 [ebuild R ] dev-libs/cyrus-sasl-2.1.19 [ebuild R ] net-www/apache-1.3.31-r2 [ebuild R ] dev-php/mod_php-4.3.8 [ebuild R ] dev-php/php-4.3.8 Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild.
ah, the -a screwed me i think :) added a `touch libgdbm.so.2` to the ebuild so the mtime gets updated and not autocleaned also updated the revdep output to say 'libgdbm.so.2'
We are getting closer, but it's still not working as I would expect. Here are my latest results: garath root # revdep-rebuild --soname libgdbm.so.2 Checking reverse dependencies... Packages containing binaries and libraries using given shared object name, will be recompiled. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Checking dynamic linking... done. (/root/.revdep-rebuild_45a0a44c.3_rebuild) Assigning files to ebuilds... Nothing to rebuild Evaluating package order... done. (/root/.revdep-rebuild_45a0a44c.5_order) There are no dynamic links to libgdbm.so.2... All done. Try to run one of the affected programs garath root # htpasswd -n pvarner htpasswd: error while loading shared libraries: /usr/lib/libgdbm.so.2: file too short garath root # ls -l /usr/lib/libgdbm.so.2 lrwxrwxrwx 1 root root 16 Jul 25 11:04 /usr/lib/libgdbm.so.2 -> libgdbm.so.2.0.0 garath root # ls -l /usr/lib/libgdbm.so.2.0.0 -rwxr-xr-x 1 root root 0 Jul 25 11:04 /usr/lib/libgdbm.so.2.0.0 Changing the cp command from cp -a to cp -aL appears to work correctly. Here are the results after modifying the ebuild garath root # revdep-rebuild --soname libgdbm.so.2 --pretend Checking reverse dependencies... Packages containing binaries and libraries using given shared object name, will be recompiled. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Checking dynamic linking... found /usr/bin/checkgid found /usr/bin/htdigest found /usr/bin/htpasswd found /usr/bin/php found /usr/lib/apache-extramodules/libphp4.so found /usr/lib/apache/libphp4.so found /usr/lib/perl5/5.8.4/i686-linux/auto/GDBM_File/GDBM_File.so found /usr/lib/perl5/5.8.4/i686-linux/auto/NDBM_File/NDBM_File.so found /usr/lib/python2.3/lib-dynload/gdbm.so found /usr/lib/sasl2/libsasldb.so.2.0.19 found /usr/sbin/ab found /usr/sbin/apache found /usr/sbin/logresolve found /usr/sbin/rotatelogs found /usr/sbin/sasldblistusers2 found /usr/sbin/saslpasswd2 found /usr/sbin/suexec done. (/root/.revdep-rebuild_45a0a44c.3_rebuild) Assigning files to ebuilds... done. (/root/.revdep-rebuild_45a0a44c.4_ebuilds) Evaluating package order... done. (/root/.revdep-rebuild_45a0a44c.5_order) All prepared. Starting rebuild... emerge --oneshot --nodeps --pretend =dev-lang/python-2.3.4 =dev-lang/perl-5.8.4 =dev-libs/cyrus-sasl-2.1.19 =net-www/apache-1.3.31-r2 =dev-php/mod_php-4.3.8 =dev-php/php-4.3.8 These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] dev-lang/python-2.3.4 [ebuild R ] dev-lang/perl-5.8.4 [ebuild R ] dev-libs/cyrus-sasl-2.1.19 [ebuild R ] net-www/apache-1.3.31-r2 [ebuild R ] dev-php/mod_php-4.3.8 [ebuild R ] dev-php/php-4.3.8 Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild. garath root # htpasswd -n pvarner New password: Re-type new password:
Just emerged the latest version of the ebuild. It appears to work as intended now.
Hm, here I get a libgdbm.so.2 with 0 (zero) length nbensa@zeddmore:/usr/lib$ ll libgdb* -rw-r--r-- 1 root root 31438 Jul 30 14:12 libgdbm.a -rwxr-xr-x 1 root root 699 Jul 30 14:12 libgdbm.la lrwxrwxrwx 1 root root 16 Jul 30 14:12 libgdbm.so -> libgdbm.so.3.0.0 -rwxr-xr-x 1 root root 0 Jul 30 14:12 libgdbm.so.2 lrwxrwxrwx 1 root root 16 Jul 30 14:12 libgdbm.so.3 -> libgdbm.so.3.0.0 -rwxr-xr-x 1 root root 17800 Jul 30 14:12 libgdbm.so.3.0.0 -rw-r--r-- 1 root root 15918 Jul 30 14:12 libgdbm_compat.a -rwxr-xr-x 1 root root 748 Jul 30 14:12 libgdbm_compat.la lrwxrwxrwx 1 root root 23 Jul 30 14:12 libgdbm_compat.so -> libgdbm_compat.so.3.0.0 lrwxrwxrwx 1 root root 23 Jul 30 14:12 libgdbm_compat.so.3 -> libgdbm_compat.so.3.0.0 -rwxr-xr-x 1 root root 7804 Jul 30 14:12 libgdbm_compat.so.3.0.0
The "zero-length libgdbm.so.2" problem is now borking xemacs-21.4.15, and presumably other ebuilds as well.
Re: Comment #16 and Comment #17: I believe that you must follow these steps: 1. Unmerge gdbm-1.8.3. 2. Merge gdbm-1.8.0-r5. This gives you a libgdbm.so.2. 3. Merge gdbm-1.8.3. This gives you a libgdbm.so.3. If you don't do step 2, then I believe the "touch" libgdbm.so.2 merely creates a zero length file. (My hunch is that this problem should only affect those who emerged gdbm-1.8.3 before the ebuild was fixed to touch libgdbm.so.2.)
No need for 1.8.0 # emerge -C gdbm # emerge gdbm # revdep-rebuild --soname libgdbm.so.2 was enough here.
Re: Comment #19: Norberto, I believe that some source files are not compatible with the new gdbm API. Thus, if you try to recompile them, the compilation will fail, unless the compatibility library is added to the ebuild. Thus, running revdep-rebuild --soname libgdbm.so.2 MIGHT fail for some packages. If the above is applies to any package, then it is better to make sure that a usable libgdbm.so.2 still exists, which is what the process in Comment #18 does. (Note: an earlier version of the gdbm-1.8.3 ebuild removed libgdbm.so.2. See Comment #13.) If someone doesn't have libgdbm.so.2, I suggest they follow the steps in Comment #18. However, this isn't necessary if they are NOW emerging gdbm-1.8.3. (Please feel free to correct any misunderstandings I am having here.)
Xemacs is still broken for me at the detect gdbm point in configure: checking for ndbm.h... yes checking for dbm_open in -lgdbm... no Error: Required GNU DBM support cannot be provided. !!! ERROR: app-editors/xemacs-21.4.12 failed. !!! Function src_compile, Line 157, Exitcode 1 This is after removing 1.8.3-r1 and re-emerging 1.8.0-r5 and 1.8.3-r1. Here is what I now have for gdbm libs: # ls -l /usr/lib/libgdbm* -rw-r--r-- 1 root root 33986 Nov 15 08:29 /usr/lib/libgdbm.a -rwxr-xr-x 1 root root 699 Nov 15 08:29 /usr/lib/libgdbm.la lrwxrwxrwx 1 root root 16 Nov 15 08:29 /usr/lib/libgdbm.so -> libgdbm.so.3.0.0 -rwxr-xr-x 1 root root 24232 Nov 15 08:29 /usr/lib/libgdbm.so.2 -rwxr-xr-x 1 root root 24232 Nov 15 08:28 /usr/lib/libgdbm.so.2.0.0 lrwxrwxrwx 1 root root 16 Nov 15 08:29 /usr/lib/libgdbm.so.3 -> libgdbm.so.3.0.0 -rwxr-xr-x 1 root root 20232 Nov 15 08:29 /usr/lib/libgdbm.so.3.0.0 -rw-r--r-- 1 root root 16442 Nov 15 08:29 /usr/lib/libgdbm_compat.a -rwxr-xr-x 1 root root 748 Nov 15 08:29 /usr/lib/libgdbm_compat.la lrwxrwxrwx 1 root root 23 Nov 15 08:29 /usr/lib/libgdbm_compat.so -> libgdbm_compat.so.3.0.0 lrwxrwxrwx 1 root root 23 Nov 15 08:29 /usr/lib/libgdbm_compat.so.3 -> libgdbm_compat.so.3.0.0 -rwxr-xr-x 1 root root 8504 Nov 15 08:29 /usr/lib/libgdbm_compat.so.3.0.0
