Can I do that? It is a minor version so I guess I should be fine?

I was thinking about grabbing the latest glibc SlackBuild and build my own package.

You can chance it. I agree, a minor version would usually be fine. I am not a software purist, and such would probably disagree. Why bother? Is there some security hole?

Why couldn't you? If you want to do that, then yes the easiest way would be to use the build material from Slackware-current (not only the SlackBuild, but all files in /source/l/glibc).

This does not imply that, see current's Changelog about the need to rebuild gcc then glibc as an example.

Advice (only an advice): unless you have a specific need or you want to do that just for fun, either run stable or current, don't mix them or be prepared to solve the problems that could occur. But that also can be fun, of course

I think that 2.20 has bit of performance gain than the last one, but I can't back it with numbers.

There are number of security fixes in it, I only needed to tweak and add one of Mancha's CVE-0475 fix for glibc 2.20.

This would be a just for fun upgrade. But I am afraid I could break my system. I guess it is safe enough then?

So I would build the latest GCC and then glibc?

I don't think it would be very fun, because something is bound to break. glibc is the heart of the system, and I would only upgrade it if it is truly warranted, never for fun.

I'll leasve you guys to your patches, and won't comment further.

For the benefit of searchers of this thread, I'll state the bit of theory we all know but nobody has mentioned. Glibc is part of the toolchain (Kernel-headers and gcc being the other 2 parts) and as such, affects basic system libs. Received wisdom is that you don't update these, because they are the basics with which the system is built.

Of the three, glibc is the fussiest, kernel headers the most forgiving of an update, and gcc comes out in the middle. Rather than update glibc from 2.15 to s.15.1 or some such, Linuxfromscratch issued a new book, and pulled the old one, indicating to all that the system should be rebuilt.

Isn't 0475 already fixed upstream in 2.20?
https://sourceware.org/git/?p=glibc....ae1e161bc8a8a3

Apparently, I was not carefully reading the release note.

Don't forget that if you are using multilib, your glibc has already been altered... replacing it with this patch at this point will almost certainly break that.

glibc should be a C standard library

anyway
unless some function was deprecated that some of the programs you run need, there shouldn't be any problem
glibc people go to fair trouble for it to be backwards compatible with older kernels
so in theory there shouldn't be any problems
in practice if something goes wrong remember to delete all the simlinks of the newer library when reverting, as upgradepkg can't do it itself

Might be a good time to use one of my favourite quotes.

2 members found this post helpful.

Never replace glibc unless you're prepared to rebuild an entire system back around it, and patch as you go.

From what I've learned with LFS, once you install a new glibc, some things must be rebuilt to the new system. Some programs may work, but others may not work. You'd have to probably build a small temporary system to use as a chroot jail, then rebuild packages for the new glibc, test, patch if needed, and lather, rinse, repeat as needed. It's a process... a long arduous process.

Go read the past changelogs and get Patrick to give you details about what is required when you rebuild glibc. It may seem as easy as building a SlackBuild, but this is just of those packages that isn't all cut and dry. Glibc, just like the kernel-headers are just two packages you do not touch outside of the aaa_* packages.

1 members found this post helpful.

This is mostly for others who may find the thread here.

ReaperX7 is right.

IMO the best approach is to do the LFS-approach - first build a
temporary toolchain. The LFS recommends to remove it lateron,
but I recommend to keep it - and re-use it. That way whenever
glibc changes, you can change it, but it is still quite annoying
since you have to recompile a lot, even when using statically
compiled programs. Nonetheless I also recommend to use some statically
compiled programs, as well as binutils for recovery.

The core toolchain set is: glibc, gcc, kernel headers, binutils. Then
there are secondary helpers: sed, awk, grep, coreutils. If you have
a working glibc, gcc and binutils, you should be able to compile most
everything though.

I don't yet know how lilo/grub play with it, but you can do things
step by step. Also make sure to know how to compile a kernel on
your own - it may help for later.

@ shevegen: please do not post in a 3 years old thread to provide an advice probably not adapted to Slackware. Unless you can alse provide a success report telling with all details how you did it on Slackware: what was the glibc version you started with, which steps you took and what was the glibc version at the end of the process.

1 members found this post helpful.