upgrading (or not upgrading) glibc
I just wanted to ask some advice from people who have probably had a lot more experience with Linux than me.
I tried to run a game using Wine and got an error message saying that a dll had failed to load and that version 2.3.4 of glibc was not found.
I am using Slackware 10.0 and the version of glibc I have is 2.3.2. I have searched the forums and the internet a bit but it seems that people have conflicting opinions on whether or not glibc should be upgraded.
So my questions are:
1. Should I attempt to upgrade glibc?
2. What is the safest way to go about this?
From what I have read I am hoping that it is possible to simply download the Slackware 10.1 package for glibc 2.3.4 and use upgrade-pkg to perform the upgrade.
I have considered just installing Slackware 10.1 but I figure that if I do that I won't learn anything.
I had a problem like that once... NEVER run removepkg on glibc. It's not fun. (Yes I'm talking from experience, just decided to reinstall everything)
I've read somewhere that you can run upgradepkg on glibc, but I don't know if that will break anything else.
thanks for clearing that up freakyg. would this just mean that it may be necessary to re-compile the kernel after an upgrade of glibc?
elyk: Yeah, i have read in some of the other forums that removing glibc doesn't work so well. I have also read about other people who tried to upgrade glibc and ran into major problems so that is why i wanted to ask for some advice first.
I updated glibc from the 2.3.4 from Slackware 10.1 to 2.3.5 from Slackware current a few weeks ago myself.
Immediately after doing so, programs started failing, the NVIDIA drivers stoped working, and the system was all in all a bit of a mess.
But nothing that wasn't fixable. I just had to recompile any program that was giving me problems. The NVIDIA driver was effected this worst, so I reinstalled/compiled that, then recompiled XFCE (I am not using the standard Slackware packages for that, I have it compiled with Composite support), and so on.
I don't recall having to recompile the kernel. I was using 2.6.12 at the time, and even after updating to glibc 2.3.5, I didn't encounter any problems.
Likely, it is one of those things that is going to be different for everyone. Some software is going to explode, and some software will be unphased.
The bottom line though, I wouldn't suggest updating something as major as glibc unless you know what you are getting into, and willing to do the work to get the system back up and running normally.
Piete-Disclaimer: I am not a programmer. All of what I spout is cause/effect related and based on experience, not a deep understanding of the underlying compilation process. What does that mean? It means feel free to enlighten me when I make a mistake =)
glibc is what programs compile against, and in most cases programs are compiled with dynamically linked libraries. As opposed to statically linked libraries.
What does that mean?
If you staticly link your program all the library functions that your program uses will be compiled into your program's final binary. So, the binary will be bigger, but may load faster, and has no dependencies.
Ooh, cool, so why isn't everything staticly linked?
Think about how many programs you've got, then imagine each of them bloating beyond belief! That's some serious code replication! And then you've got your libraries (glibc, libogg, fftw etc etc etc) on your box *as well* to compile against!
But in an age where 500GB hard drives exist, what's the problem?
Meh, who knows. Anyway, the result is, most stuff is compiled dynamically, so that means when you remove glibc (or change it's version), you remove parts of your existing programs (because when they run, they call the library functions, not internal functions).
The kernel doesn't compile against glibc, so won't be affected.
So, uh, you're great and ... well ... what do I do?
Check your reasons for upgrading glibc.
* To run a single program you could recompile the program yourself, which would then work with your version of glibc.
* Find a package that has been compiled for Slack 10.0, not 10.1
* You could run "upgradepkg" on your system, which would take it from Slackware 10.0 to whatever version you liked.
I won't go into it here, but needless to say, there are numerous online-update tools (search the forums for: swaret or slapt-get) that you can use to do a bulk upgrade, or you can do it "manually" by downloading the packages you want (or the ISO, since that's likely to be less time consuming) and then doing something similar to the following:
* Backup any editted config files (/etc) and anything you've tweaked (I tweak startx, so that gets backed up). If you can afford the space, it's always a good idea to dump an image to disk, that way, the upgrade is risk free. If it goes horribly wrong - you can restore your old system precisely how you left it.
* mount -o loop /path/to/new-slack.iso /place/to/mount
* upgrade pkg /place/to/mount/slackware/*/*.tgz
It'll run through every package, starting with the a/ directory and upgrade the packages you have installed. When it's done, you'll have essentially installed a newer version of Slackware, but without loosing your config files =)
Uhm, apologies for the length of the post. I get carried away when I see people messing with toolchains ... I should probably see a doctor about that, actually.
My advice would be a manual upgradepkg. It's easy and pretty painless. Just be aware that if you've still got the kernel modules and kernel packages installed, it will upgrade them and reinstall lilo, so you may have to edit lilo.conf and/or reinstall (make modules_install && make install) your custom kernel.
Take it easy, and don't forget - pretty much everything is fixable!
- Piete "Quick! Someone's discussing toolchains! Must. Get. Into. Conversation!" Sartain.
PS: I second MS3FGX's statement:
PPS: It's not meant to be a scare post.
Thanks for the advice guys. I have a couple more questions:
Is it possible to have two separate versions of glibc installed at the same time and install different programs against different versions?
and secondly, Piete, you said:
"* To run a single program you could recompile the program yourself, which would then work with your version of glibc."
what would this involve? Does this mean editing the source code of the program?
For a more complex program, read the manual! Having a look over at www.winehq.org shows me that actually their install from source proceedure is very much the same as mine! For instructions, straight from the developers, read here: http://winehq.org/site/docs/wine-use...ng-wine-source
I tend to go off on tangents, so please do say if you want anything clarified. I would say, however, that all the information is out there and Google (www.google.com/linux) is your friend!
Thanks again for your help Piete. I think I have some reading to do :)
I have not been using linux for long and am used to the Windows way of doing things and I thought that the error meant that my version of glibc wasn't high enough and that I had to upgrade it. I understand now and I think I know why it wasn't working. I used the Slackware 10.1 package and Slackware 10.1 has glibc 2.3.4 instead of 2.3.2, so wine expected me to have 2.3.4 when I don't.
I have done some compiling of packages from source before so I know the basics. I haven't used checkinstall before but have heard of it and what it does so i will do some googling and reading up on it.
PS: Don't worry if you keep going off on tangents. It just means I learn more :)
If you bdo decide to upgrade GLIBC, you can do it more safely by doing it remotely. I mean, don't upgrade a running system -use the install CD to boot and mount your installation on /mnt. Then run removepkg and installpkg to install the new libs.
This will prevent you from having a non-bootable system, but it may still break some programs.
|All times are GMT -5. The time now is 01:29 PM.|