Bug 66538 - rpm not robust: uses shared libpthread.so
rpm not robust: uses shared libpthread.so
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Depends On:
  Show dependency treegraph
Reported: 2002-06-11 17:34 EDT by John Reiser
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-06-11 17:34:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Reiser 2002-06-11 17:34:35 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.19-6.2.16-KRUD-perfctr2.3.6

Description of problem:
In RedHat Linux 7.3/i386, the /usr/lib/rpm/rpm* family is dynamically
linked so that many of the executables depend on libpthread.so.
This makes many rpm tasks, including --query and --verify,
significantly less reliable and robust, especially during
and after installation and upgrade, just when you wish to
rely the most on rpm.
libpthread is not yet at 1.0 release, its external interface
is changing rapidly, and fundamental system tools should not
rely on such risky environments.  RedHat Linux 7.2/i386
did not have this dependency (/usr/lib/rpm/rpm* were static linked).

Example: I had /lib/i686/libpthread.so symbolically linked
to a private copy based on glibc-2.2.4-24 and containing
some bug fixes.  I upgraded from 7.2 to 7.3, and was left
with "rpm --query" and "rpm --verify" not working, even though
the anaconda upgrade "succeeded".  Mechanism: my libpthread.so
had _dl_cpuclock_offset as an undefined external (resides in
/lib/ld-2.2.4.so), but _dl_cpuclock_offset
is not in glibc-2.2.5-34, so dynamic linking libpthread.so
failed after the upgrade.  The upgrade did install the new
/lib/i686/libpthread-0.9.so, but did not notice that libpthread.so.0
was linked to libpthread-0.9.so.mine, and did not change the symlink.

Whatever the reason, having --query and --verify depend on
libpthread.so is a bad idea.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. On a 7.2 system:
   cd /lib/i686
   cp libpthread-0.9.so libpthread-0.9.so.mine
   rm libpthread.so.0
   ln -s libpthread-0.9.so.mine libpthread.so.0
2. Upgrade from 7.2 to 7.3
3. Reboot.  Notice that "/bin/sleep" and "rpm --query"
   don't work anymore.

Actual Results:  Any executable that DT_NEEDED libpthread.so.0 fails during
dynamic link: _dl_cpuclock_offset missing.

Expected Results:  /lib/i686/libpthread.so.0 should have been pointed
at the new libpthread-0.9.so [anaconda rpm bug],
and it should not have mattered anyway because
/usr/lib/rpm/rpmq should not depend on dynamic libpthread.

Additional info:
Comment 1 Jeff Johnson 2002-06-12 11:19:46 EDT
For better or worse, rpm is no better than
the bits in the operating system, pthread included

Meanwhile, robustness is provided by editing
/usr/lib/rpm/rpmpopt-x.y if/when necessary. Commenting out
the popt aliases used to re-exec the helper binary
(which is shared), re-enables the query/verify modes
still present in (statically linked) /bin/rpm.

Note You need to log in before you can comment on or make changes to this bug.