Just upgraded from source to glibc-2.2.5, to clear up an instalation problem where a program was complaining about 2.1.x (software still won't install, but that is not my trouble now -- that may be bad media). The upgrade included a linuxthreads add on package. I am getting an error when initiating a few programs -- "/usr/local/lib/libpthread.so.0:undefined symbol:_dl_cpuclock_offset" All I really know is it is related to linuxthreads, as the libpthread.so's are installed with that. Tried recompiling and installing various things (upgraded a few other outdated libraries and such in the process), but have had no luck with this error. I can still run many things that use glibc extensively, but unfortunately the ones that won't perform are some of my most used .

Any suggestions would be greatly appriciated
Thanks!

Did you by any chance also added the crypt, and linuxthreads sub directories to your source before compiling?

If you did not, then you can download them from here.

Make sure you read the README in the glibc archive so you understand what you need to do.

GL

P.S. I don't believe you may need the crypt package, but I am not sure about that. I have not compiled glibc in a while. . . I am sure the README will help you with that.

/edit: Added P.S.

Well, added the linuxthreads directory, and the linuxthreads.db directory, but not the crypt (?which I will look into, thanks) -- everything seemed to chug along fine in the make install, and it referenced writing linuxthreads files in it's feedback.

I found some references to an out of date ld.so being the possible culpret to this problem (did a search with "alltheweb" and apparently it is a common problem, with no obvious solution I could find).

So, now I have a new problem...hey, at least I'm busy. Installed the most recent version of ld.so, and....then I got the _dl_cpu_clock_offfset when I tried to simply "startx"!

I deleted the file libpthread.so.0 file, and got X running again, but a simple "ls" command in bash gets the offset error (citing librt.so.1). Now my DCgui runs, tho (which was one of the programs I lost to the old so.0 error). Sooo, I am going to RE compile, yet again the glibc, and at the same time look for some alternate method to install libthreads, which still seems to be the offending thing, somehow. Also, I am going to remove all traces of libthread related files and see if I get my shell functionality back. Not that I'll leave it that way, it is just a process to narrow down what is going on.

In the meantime, any other suggestions are truly appriciated.

You just reminded me why I rarely compile glibc unless there exists a major bug fix. Whenever you upgrade glibc (with whatever other packages you decide to include), it can pretty much affect (ALMOST) every single application you may have in your system. Even if you compile it correctly.

As you are finding out. . .

BTW, are you running ldconfig -v after you done with the installation? By running the above command, you can make sure your new libs are set up right and updated.

Also, make sure you remove the old instance of glibc-2.1 with the package manager. . .

HOWEVER, I would just suggest to you to get the slackware packages for glibc-2.2.5 instead, that way it can be much easier for you to upgrade the libraries. If you decide to get the package for Slackware, you can get the slackware package for glibc here and simply use the upgradepkg <old_package>%<new_package> command. Make sure you get the i18n package as well, and install it (or upgrade it if you can).

That way, it will be easier for you to manage it in the future for any other future upgrades.

GL

Argh! Woulda used the slack packs in the first place, but the download at the Project was empty (I'm bookmarking your source, although I'm sure it won't last forever). Lets see if I can restore things to an acceptable state, thanks for the help!

Welp, everything is back the way it used to be...right after I installed the upgrade . Dcgui giving me the cpuclock_offset error. At least now I know that if I totally screw everything around, I can put it back the way it was...to this point, at least.
I must say, though LNXman, u have been quite a help...and I always come out of these things wiser thanks to contributors like yourself.

Back to the problem, tho...I believe that the slack pack of glibc had the threads additions built in...so I'm not sure how that still bears on my previous assumption that the problem was there, as I have installed all the slack packages for glibc now. Back to researching, I guess. Lemme know if anything else comes to mind.

Well, as the day (night) ends..it stands that if I delete libpthreads.so.0 I can run whatever I wish. Rebooting restores the file, and the problem returns, until it is deleted again.

Aight fixed it, and will post this solution also in reply to the other poor soul having the same problem elsewhere on this forum.

The linuxthreads package that was included as an add-on with the glibc I compiled and installed (the newest version available from the GNU peeps) corrupted my poor slack.

I uninstalled the packages glibc-2.2.5 and glibc-solibs, then going in by way of the distro cd (as after those deletions nothing worked, nor was expected to), I removed everything that started with libpthread (rm libpthread*) from /user/local/lib in my installation (these all shoulda gone bye bye when I removed those packages, but they didn't..aha!). Then using pkgtool, I reinstalled the glibc slack packages from where I had saved them in my home directory (didn't wanna put the old ones from the original distro on again).
No more worries.
Thanks again.

Good job.

I seems you may have had a lot of garbage lying around from your previous attemps to install glibc. Way to keep chucking at it!!!

L8

i'm having a problem similar to yours. but i don't understand everything that was said in this exchange. could you please post a brief recap of what you did in order to upgrade glibc?

i tried compiling glibc from scratch, but when i installed it my system became unbootable. i had to use the rescue partition to recover.

i tried installing glibc from various rpm's, but there were so many circular dependencies that i gave up.

i never did succeed in getting the new glibc installed.

the reason i want to install a new glibc is so that i can run the new mozilla. i also tried building mozilla, just to see what would happen. the build gives an error, complaining about not being able to find _dl_cpuclock_offset .

i could sure use some expert advice...

thanks in advance.

Well, that was a year ago...but reading my posts and rmembering to the best of my ability, the problems arise when the old glibc isn't completely removed when a new one is installed.

Remove glibc and glibc-solibs for your system, either through package management or "make-uninstall". Use your rescue disk to acces your instalation and go to your old /usr/local/lib (or wherever libpthread* is kept in your distro) and #rm libpthread*. At this point it would help to know what distro you were running to say for sure how to proceed, but if it uses package management of some kind (if you are having circular dependancy problems sounds like you might be using apt ) install your new glibc using the commands appropriate to your distro to ignore dependancies.

hey, thanks for your quick answer.

i'm running a redhat distribution. it's started out as an old version of redhat, but it's got pieces of redhat 7. i'm kind of squeamish about removing glibc, but i'll consider it. it just seems to me like there would have to be a better way.