"The Linux Gazette...making Linux just a little more fun!"

Upgrade Breaks Several Programs, /proc Problems, BogoMIPS Discrepancies

A visit to "Library Hell"

From Pete Caffall on Thu, 27 May 1999

Jim:

I'm kind of going nuts here trying to figure this one out. I have just recently upgraded my system at home with RedHat 5.2. It previously had RedHat 5.0 on it. Since then I have been unable to get Netscape (4.5.1 or 4.06) to work, as well as Word Perfect 7.0 , and not to be outdone - arena. All break on start up with a segmentation fault (SYSSEGV) and a core dump. Prior to the upgrade, all worked (well - don't know about arena - just tried that to see if it might also break). I did not change my hardware configuration and is the same as prior to the update. ASUS 5ab MB, AMD K 6 II 3D 333mhz processor, 64 mb 100mhz sdimm, 5 gb WD IDE hd drive where Linux is installed. XFree86, Afterstep that came with the distribution, and ATI Xpert 98 video with 8mb.

It sounds like the upgrade replaced your shared libraries with versions that aren't quite compatible with these applications. Netscape Navigator and Communicator have both historically been pretty picky about their shared libraries.

There are occasions in the past where a GNU bug fix to their libc has broken versions of Navigator and Communicator that relied upon these bugs. You can find out which libraries these files are linked against with the 'ldd' command.

You can also rebuild your /etc/ld.so.cache file by running the 'ldconfig' command (a good idea to try that any time you suspect shared library problems).

You say (later) that you tried using libc.so.5.4.33. However you don't say how you tried to use it. There are a couple of magic environment variables LD_PRELOAD and LD_LIBRARY_PATH which can be used to override the order in which shared libraries are loaded (and thus can control which library gets loaded to supply a given set of functions).

You can read the ld.so(8) man page for some details about how the linker/dynamic for shared objects works under Linux and other GNU systems.

Typically you'd copy your old libraries (with which these programs were working) into some directory (/usr/local/lib-special for example) and then replace your links to Navigator, Communicator, WordPerfect, and any other affected programs with a short wrapper script that sets and exports the appropriate environment variables and then launches the original program. There are examples of such scripts on the web (from people who've had to hack them up to run earlier versions of Navigator after earlier upgrades of glibc).

Most of this nonsense should be unnecessary under Linux. First, programs should be written to rely on the exposed/documented characteristics of the libraries against which they are linked. Also it's supposed to be possible to linked to more specific library versions in cases where the more general version won't work with your application. That's why we have so many symlinks like these:

-rwxr-xr-x   libc-2.0.7.so
lrwxrwxrwx   libc.so.4 -> libc.so.4.7.6
-rwxr-xr-x   libc.so.4.7.6
lrwxrwxrwx   libc.so.5 -> libc.so.5.4.46
-rwxr-xr-x   libc.so.5.4.46
-rwxr-xr-x   libc.so.5.4.7
lrwxrwxrwx   libc.so.6 -> libc-2.0.7.so

(from /lib on one of my S.u.S.E. systems, actually).

The idea is that we should be able to have a libc.so.4.6.XX with a symlink to libc.so.4.6. libc.so.4.7.6 (from my example) would still be the "default" for libc.so.4, but programs that were linked to libc.so.4.6 would use our libc.so.4.6.XX. Thus they would be more specifically bound to the 4.6 versions of the libraries than to the 4.7 or 4.5.

This is far more flexible than the implementation of DLLs we see in MS Windows and NT. It can automatically tolerate multiple concurrent versions of each library. The LD_PRELOAD and LD_LIBRARY_PATH environment variables give us even more flexibility since we can override the linkage at run time for a specific process (or family or processes).

However, it can be a pain to manage for mere mortals such as myself. Oddly enough it also seems to be more of a problem for the commercial packages than for other Linux software. I have to cope with far less "library hell" resulting from typical binary packages than I do with the big commercial ones.

I supposed one thing that WordPerfect, Netscape, Applix, and Star Division could all do is to include all of the libraries that they require (with which they are linked and tested) on their CDs. They could then have an installation and/or configuration option to install those in a special directory (/opt/${PACKAGE}/lib) and to automatically invoke their programs in a "compatability mode" where they set their own LD_PRELOAD variables properly and launch thier binaries.

Such a scheme could allow these companies to be more robust in the face of distribution updates (such as your transition from Red Hat 5.0 to 5.2 and the more disastrous change from 5.x to 6.0 that has broken StarOffice and other packages for so many Red Hat users in recent weeks).

(At the same time these packages would not need to take up the additional disk space and memory footprint when running on a system whose default libraries are suited to the situation).

In any event you might consider upgrading to RH 6.0 and WP 8.0. I personally suggest letting the distribution maintainers do as much of the work of getting you out of "library hell" as possible.

One thing I have noticed -it had problems trying to mount the /proc file system - boot message indicated that it couldn't find /proc in the fstab or mtab. I didn't notice it the last time I booted, and looking in /proc, it shows as a file system, although df -a doesn't show it. I tried using the libc.so.5.4.33 but this did not resolve the problem.

I presume that your reference to libc.so.5.4.33 relates back to your problems with certain applications since the /proc issues are very unlikely to relate to your shared libraries.

Classically the 'mount' command should be statically linked. I notice that S.u.S.E. 5.2 and Debian 2.1 and Red Hat 5.2 all have it dynamically linked against libc. This is BAD (since a corrupt ls.so.cache or a damaged libc.so will then prevent you from even mounting up an alternative filesystem). There is an alarming trend to configure whole systems to practically require dynamic linking for everything. This makes the whole system less robust with greater and more critical interdependencies. (In this regard we are following in Sun's footsteps; it's practically impossible to create a statically linked program under Solaris).

However, I doubt that your problem with /proc has anything to do with shared libraries.

Your mtab file should initially be empty when your reboot. Your /etc/fstab file should have an entry from /proc that looks something like:

none     /proc        proc       defaults      0 0

... If it doesn't, add one.

Any suggestions (nice ones) would be appreciated.

One curiosity question: The system at home with the AMD K6 II 3D reports 663 bogomips. The system I have at work is a Pentium II (not Celeron) 400 Mhz, and it reports 397 bogomips. What gives. Thanks in advance for any help you can give.
Pete Caffall

I wouldn't worry about it. BogoMIPS are a measure of how fast your processor executes a fast idle loop. That is to say, how fast can your processor do NOTHING. In most cases a stock Pentium CPU will have a BogoMIPS value that's reasonably close to its clock speed. However Pentium MMX and various clone CPUs with MMX like extensions (like your AMD K6) will have higher BogoMIPS values.

My Pentium 150 shows:

cpu MHz                : 167.050963
bogomips        : 66.56

(excerpts from /proc/cpuinfo) while my Omnibook 800 (Pentium 166) shows a BogoMIPS of 328.50. My old 386DX/33 shows a BogoMIPS of about 6.6

There's a reason why Linus named these "BOGO"-MIPS

(I guess they're actually used in the kernel for certain types of short idle loops).

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 42 June 1999

HTML transformation by of Starshine Techinical Services, http://www.starshine.org/

	1	2	3	4	5	6
	7	8	9	10	11	12
	13	14	15	16	17	18
	19	20	21	22	23	24