recompiling glibc on slackware 10.2
 

i really like all the updated packages and stuff in 10.2 compared to 10.1... but i am having issues with 10.2 which i don't have in 10.1 and i suspect it's because of the glibc changes done in 10.2 (NPTL)...

i don't really know a lot about libraries and compilers and stuff but i'm trying to learn... what i would like to do is not have to go back to 10.1, so i'd like to keep my 10.2 but i'd like to make it as though the NPTL changes never happened... in other words i'd like to have a glibc and stuff similar to the one in 10.1...

what steps should i take in order to do this the right way??

i have never recompiled glibc so i don't know the implications this could have... i also don't know what other steps might need to be taken after recompiling it... for example, would i need to recompile the kernel after recompiling glibc??

any help you could give me with this would be great... :study:

Could you explain your issues, are they like :
glibc detected *** double free or corruption: xxxxxxxxxx ***

For my part, I do the reverse, eg compile the libs and bin that need pthread with :
before a ./configure and make

well, the issues are mainly some system freezes using some apps... but please let's not get into that, i would want to do this even if i wasn't having problems... it will be an educational experience even if it doesn't solve the issues i am having...

so is it just a matter of taking the glibc build script from 10.1 and using that?? what else would i need to recompile??

You can compare the build scripts from 10.1 and 10.2 and see the differnce. They are not quite different.

yeah, i took a quick look yesterday... seems like the main difference is all the NPTL crap... i'm gonna try and recompile the glibc from 10.2 using the build script from 10.1 later tonight... we'll see how it goes...

slackware is very dull

go away.

Win32sux: let us know your results, I'm quite interested in this

glibc is one third of something called the toolchain (glibc + gcc + binutils), which have circular dependancies. That is to say, they all depend on each other.

Upgrading (or changing) your glibc may break gcc and binutils, and of course, with them broken, you can't downgrade glibc again.

Ok, no problems, reinstall the packages ... but, whoops ... glibc is linked from bash, ls, cd, mv ...

So now you've bust your system.

I would recommend building a completely new toolchain and leaving your existing stuff in one place, that way you can make as many mistakes as you like without risking your system.

Check out crosstool: http://kegel.com/crosstool/

Although it's been designed to build self hosting cross-toolchains, you can always point it at your arch and build a self-contained second toolchain.

Once you've got the hang of it, and ironed all the bugs out of your toolchain (often there are patches and fixes that need applying en route to toolchain-haven), you might consider rebuilding (and repackaging) your desired version of glibc and link against it binutils and gcc, giving you a whole new toolchain that you can upgrade to.

It's worth pointing out, tho', that even this sort of change may stop everything that links against glibc from functioning, so you'd then have to recompile all your packages against this new toolchain (not impossible if you have a second self-hosted toolchain that you can use to build these packages *before* upgrading).

The crosstool, gcc & glibc mailing lists have loads of information on how things are put together, as does linuxfromscratch (http://www.linuxfromscratch.org/).

Good luck!
- Piete.

thanks for the reply... :)

but then how does Pat manage to recompile glibc without having to touch gcc and/or binutils?? take a look at the changelog, glibc has been recompiled many times without having to change anything else... for example:http://www.slackware.com/changelog/stable.php?cpu=i386

BTW, i'm not trying to upgrade it or anything like that... i'm gonna keep the same version, i just want to recompile it in the style of 10.1 (no NPTL stuff)...

I tried this once and it broke every binary on my system. :-) I had built my entire system against a 2.6 kernel and a threaded glibc tho. When I downgraded to a non NPTL glibc, all hell broke loose. Couldn't run a single binary on my system. Got all sorts of wierd ld errors and what not.

I'd like to know how Pat got away with switching to an NPTL glibc midstride... I'm thinking it's because the entire system was still built against a non-threaded glibc and 2.4 headers. As far as I'm aware, 10.2 was not a complete recompile. So adding a threaded glibc wouldn't have an effect because the entire system defaults to not looking to use threads anyway. linux-2.4.xx isn't capable of supporting it.... So that leads me to believe that nothing on a stock 10.2 install will be capable of using threads to begin with. I'm assuming he added a threaded glibc so you could compile your own stuff to have thread support.

That's my take on it... Whether or not I'm even close, I don't know. Let us know what happens. Now, when Pat goes for a complete recompile against 2.6 headers ( I assume 11.0 ), I wouldn't even dream of trying to downgrade. You'll open up a can of worms if you do.

have you taken a look at the README.NPTL?? ftp://ftp.oregonstate.edu/pub/slackw....2/README.NPTL

as you can tell i know very little about this issue, but it seems like Pat hints at what it took in that file...

BTW everyone, i'm getting ready to go forward with the glibc recompile, but i want to upgrade my kernel (to 2.4.32-rc1) also... right now i'm trying to remember how to go about making a new kernel-headers package... once i have that down, i will proceed... i'm thinking it's gonna go something like this:
does that sound about right?? :study:



BTW, i asked over here about making the headers package if you wanna help me out with that: http://www.linuxquestions.org/questi...21#post1889121