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:
Quote:
|
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.
|
PPS: It's not meant to be a scare post.
PPPS: Really.
