-   Slackware (
-   -   recompiling glibc on slackware 10.2 (

win32sux 10-05-2005 12:43 PM

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:

keefaz 10-05-2005 12:52 PM

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 :

export CFLAGS=-I/usr/include/nptl
export LDFLAGS=-L/usr/lib/nptl

before a ./configure and make

win32sux 10-05-2005 01:11 PM

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??

batev 10-06-2005 08:29 AM

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

win32sux 10-06-2005 12:22 PM


Originally posted by batev
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...

TigerLinux 10-07-2005 12:01 AM

slackware is very dull

phil.d.g 10-07-2005 05:04 AM


Originally posted by TigerLinux
slackware is very dull
go away.

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

piete 10-07-2005 11:14 AM

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:

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 (

Good luck!
- Piete.

win32sux 10-07-2005 11:33 AM

thanks for the reply... :)


Originally posted by piete
Upgrading (or changing) your glibc may break gcc and binutils, and of course, with them broken, you can't downgrade glibc again.
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:

Sat Sep 10 22:21:22 PDT 2005
OK, everything was set in stone except for these things. ;-)
There may still be a couple more changes (maybe), but this is pretty close.
a/aaa_base-10.2.0-noarch-2.tgz: Fixed rp-pppoe version number in email
to root. (thanks to Piter Punk)
a/aaa_elflibs-10.2.0-i486-2.tgz: Upgraded glib libraries to 2.6.6.
a/bash-3.0-i486-3.tgz: Added bash patch bash30-016.
(suggested by Fredrik Rinnestam and Xavier Thomassin)
Added a patch to prevent an issue with newer glibc versions and 2.4.x
kernels that leads to a bash hang if bash is recompiled on such a system.
(Thanks to Fredrik Rinnestam)
a/glibc-solibs-2.3.5-i486-5.tgz: Recompiled against header files from
linux 2.4.31 (linuxthreads version) and linux 2.6.13 (NPTL version).
a/glibc-zoneinfo-2.3.5-noarch-5.tgz: Rebuilt.

ap/vim-6.3.086-i486-1.tgz: Upgraded vim to patchlevel 86, and upgraded to
l/esound-0.2.36-i486-1.tgz: Upgraded to esound-0.2.36.
l/glib2-2.6.6-i486-1.tgz: Upgraded to glib-2.6.6.
l/glibc-2.3.5-i486-5.tgz: Recompiled.
l/glibc-i18n-2.3.5-noarch-5.tgz: Rebuilt.
l/glibc-profile-2.3.5-i486-5.tgz: Recompiled.

l/gtk+2-2.6.10-i486-1.tgz: Upgraded to gtk+-2.6.10.
l/pango-1.8.2-i486-1.tgz: Upgraded to pango-1.8.2.
Thanks to Giacomo Lozito for pointing the bugfix releases of glib, gtk+,
and pango out. The 2.8 series still needs time to stabilize and may present
some compatibility issues (just a guess), and the version bump on atk-1.10.1
makes me want to play it safe on that one as well. We'll get to those in the
next -current.
l/sdl-1.2.9-i486-1.tgz: Upgraded to SDL-1.2.9, SDL_image-1.2.4,
SDL_mixer-1.2.6, and SDL_ttf-2.0.7.
n/nmap-3.90-i486-1.tgz: Upgraded to nmap-3.90. (suggested by many :-)
n/wget-1.10.1-i486-2.tgz: Change /etc/wgetrc to /etc/ so that it'll
be protected from replacement the next time this package is upgraded.
Suggested by Luigi Genoni.
xap/xvim-6.3.086-i486-1.tgz: Upgraded X version of vim to patchlevel 86, and
upgraded to ctags-5.5.4.

Wed Jul 20 16:17:08 PDT 2005
a/glibc-solibs-2.3.5-i486-4.tgz: Recompiled, as I forgot that with both
linuxthreads and NPTL versions of glibc that the patch would have to be
applied twice. Thanks again to Dirk van Deun for pointing out my error.
a/glibc-zoneinfo-2.3.5-noarch-4.tgz: Rebuilt.
l/glibc-2.3.5-i486-4.tgz: Recompiled.
l/glibc-i18n-2.3.5-noarch-4.tgz: Rebuilt.
l/glibc-profile-2.3.5-i486-4.tgz: Recompiled.

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)...

jong357 10-07-2005 12:05 PM

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.

win32sux 10-07-2005 01:35 PM


Originally posted by jong357
I'd like to know how Pat got away with switching to an NPTL glibc midstride...
have you taken a look at the 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:

- recompile kernel-ide and kernel-modules...

- recreate kernel-sources and kernel-headers...

- recompile glibc...

- recompile alsa...

- recompile nvidia...

does that sound about right?? :study:

BTW, i asked over here about making the headers package if you wanna help me out with that:

All times are GMT -5. The time now is 12:10 PM.