rh9 / 4363 breaks open office and xmms

[athlonuser]

mobo - epox 8kta3
proc - athlon 900
video card - GeForce2 MX 400
video bios - 03.11.01.26.02
driver - Linux-1.0--4363
distro - rh9 (2.4.20-6 kernel)

both xmms and openoffice fail to even start.
both programs showed similar behavior under the previous (-4349) driver.
i'd seen mention of the later 2.4.20-9 kernel patch in the discussion threads. should i give this a shot before doing anything else?

[bwkaz]

I'd at least try it, though I don't know how much it'll help.

When you say they don't start, what actually happens? Run them from a terminal, and see what gets printed.

[athlonuser]

looks like segmentation fault for xmms, don't know how to start openoffice from shell...
will have to download the 20-9 kernel patch. as i'm on dialup it may take a bit. thanks for the response.

[bwkaz]

I think you can start OpenOffice with ooffice, but I'm not sure -- hit oo, then hit the tab key a couple of times to see what it thinks exist, in the way of executables that start with "oo".

[athlonuser]

the oofice seemed to do the trick, unfortunately it returned the same "segmentation fault" as xmms seemed to. still downloading the kernel patch, so we'll see.

[bwkaz]

Maybe doing something like export LD_ASSUME_KERNEL=2.2.5 before starting xmms might help? If it does, then redo the nVidia drivers, but pass --force-tls=new to the installer.

I remember a very few people who couldn't get the installer to detect their glibc / kernel TLS support correctly; you might be having that same problem. Maybe. Try the LD_ASSUME_KERNEL thing first.

[athlonuser]

the export L_ASSUME_KERNEL_2.2.5 worked beautifully. it ran both programs but while running xmms reported

libGL.so.1: cannot handle TLS data

now should i uninstall the nvidia driver, then do the

sh NVIDIA-Linux-1.0-4363.run --force-tls=new

[Andy Mecham]

You need to upgrade your glibc package - the boxed version of RedHat 9 shipped with a broken glibc. That's the source of your problems.

--andy

[athlonuser]

so after downloading and installing the new and improved glibc i need to reinstall the nvidia drivers or is simply installing the non-broken glibc enough?

[Andy Mecham]

The tls_test in the installer might have failed, depending. It's probably best to reinstall the driver to make sure the TLS libraries are installed. You shouldn't need to force them.

--andy

[athlonuser]

tried the glibc i686 upgrade rpm, the 2.4.20-9 i686 kernel upgrade rpm, uninstalled and reinstalled the nvidia drivers after both, still needed to use the
export LD_ASSUME_KERNEL=2.2.5
to make xmms and openoffice jump.
even tried to force the tls as bwkaz mentioned trying and it still didn't help.

[bwkaz]

Just to make doubly sure the glibc update happened, what does running /lib/libc.so.6 tell you, in the first line, where it has the version string?

[athlonuser]

first line reads
GNU C Library stable release version 2.3.2, by...

[bwkaz]

Is that the updated version then?

I probably should know, but I don't...

[bahamot]

run just fine here :)

[athlonuser]

sorry, i didn't know enough to run the libc check before the change so i don't know either. :)

[bwkaz]

Rats... umm...

This is worth a shot -- does the version printed by rpm -qa | grep libc match what /lib/libc.so.6 says?

[kremit]

I had those same problems when GLX wasn't being loaded. XMMS tried to load its openGL-powered plugins, and it crashed.

Have you checked to make sure GLX is being loaded?

[athlonuser]

sometimes when i attempt to reply here i get bounced out after logging in and composing a reply, necessitating a second try at doing the whole process again. rather annoying actually.

during the glibc upgrade process i tried using the srpms at the redhat site and after building them (they oddly enought turned out to have an i386 in the filenames) i attempted to install them and were stymied with dependency problems, supposedly not having the requisite 2.3.2-5 packages. i then went up to the redhat site and pulled down and installed (i thought) the i686 versions of the glibc and 20-9 kernel rpms.
here's what the rpm -qa | grep libc returned

glibc-debuginfo-common-2.3.2-27.9
libcap-1.10-15
glibc-kernheaders-2.4-8.10
libcapplet0-1.4.0.1-11
libcap-devel-1.10-15
dietlibc-0.21-4
glibc-common-2.3.2-5
glibc-devel-2.3.2-5
glibc-profile-2.3.2-27.9
glibc-utils-2.3.2-5
libcapplet0-devel-1.4.0.1-11
glibc-2.3.2-5
glibc-debug-2.3.2-5
glibc-debuginfo-2.3.2-27.9

/lib/lib6.so.6 doesn't return anything past the 2.3.2, such as a -5 or a -27.9, so i'm guessing that it didn't get upgraded...

[bwkaz]

It may just not be telling you that. gcc does something similar -- regardless of the patchlevel of your gcc, it'll only tell you the "official" version numbers. If you're running 3.2.1-7 (or something), for example, then gcc -dumpversion will only tell you 3.2.1.

So it still may have been upgraded.

Can you look around on your CDs for which version is included there? If it's 2.3.2-5, then try upgrading more than just glibc-profile and glibc-debuginfo. I don't suppose you have RHN access, do you? That'd make it easier...

[athlonuser]

went out and actually bought the personal distro, installed it from zero and ran the red hat network up2date thang. took long time downloading all the packages with just a dialup, and it reported that there was a problem with the kernel docs during download. i said alright go on and finish the install, and away it went with the install, but when i checked it a couple of hours later, it had stopped at the kernel doc package. it had, fortunately, installed the glibc package, the 2.3.2-27.9 rev that was needed for the problem that we've attempting to address. i futzed about with some other things (hosts, fstab, email client, etc) before trying the .4363 driver install, but it came off without a hitch and xmms started properly. btw, the compile date on the 2.3.2-27.9 is an april date while the 2.3.2-5 is a february date.
thanks for your help and i guess the moral of the whole mess has been to make sure that the latest errata packages have been installed properly before crying wolf...