Description of problem: Upgrading to rh8 from rh7.3 version of rpm fails, althought it looks as if it worked (that is, the rpm -U works, but the program doesn't). With the rh8 version of rpm, I get a ld.so? error as follows: /usr/lib/rpm/rpmq: relocation error: /usr/lib/librpmdb-4.1.so: undefined symbol: poptSaveInt In trying to sort this out: 1. I reverted to the original 7.3 version of rpm; this works, but of course there are some package-compatibility problems (e.g. up2date). adequate, but not desireable. 2. I fetched the rpm-4.1 tar file, compiled it and installed it (using prefix=/usr). The result was indistinguishable from the pre-packaged version. 3. I (in desperation) decided to try the rawhide version of rpm. This required upgrading of glibc, which I checked and decided ought to be safe-ish. Might have been wrong there, because although most programs still work, when I try to use rpm-4.1 to upgrade something (e.g. to rpm-4.2) I get the error: "cannot cope with TLS data". I note that glibc is now installed in /lib/tls -- what is tls (other than transport-level-security, which doesn't make sense to me in this context). Note that in most cases, the rpm option to upgrade a package works; it's -- erase, --query that fail. However, (3) above has resulted in an rpm that cannot upgrade, although it does manage the initial check. Hoping you can help :-) There is a thought in my mind that it is an rpmdb problem, not strictly rpm, but I am confused... Version-Release number of selected component (if applicable): glibc 2.2, glibc 2.3, rpm-4.0.4, rpm-4.1, rpm-4.2 How reproducible: Very Steps to Reproduce: 1. rpm -q rpm Actual results: /usr/lib/rpm/rpmq: relocation error: /usr/lib/librpmdb-4.1.so: undefined symbol: poptSaveInt Expected results: rpm-4.1
You needed to upgrade popt when you upgraded rpm.
I did upgrade popt: indeed, I also verified it's upgrade with rpm -verify and rpm -U against the rpm file from the distribution. It is possible that the wrong library is being found somewhere, but how can I tell? However, I have just tried again, and it seems to work :-) I didn't reboot straight away (wanting to make sure that when I did reboot, it would still operate properly). Is it possible that the wrong popt library was in memory still, and so was linked in preference to the correct one?
/sbin/ldconfig is run when popt is installed/erased so a running memory image is unlikely to be the explanation.